MS SQL: Wechsel von ADO zu SDAC, UniDAC oder sonstwas?

[Schokohase]

Nun ja, zum Thema FireDAC, Enterprise, auf eine Komponente muss man sich einigen ...

Dazu hätte ich ein entschiedenes Nein.

FireDAC ohne Enterprise kann nur mit lokalen Datenbanken arbeiten. Gut, dann bauen wir einen REST-Server (z.B. mit MARS) der dann auf der gleichen Maschine läuft wie der Datenbank-Server (und schon ist der lokal und erreichbar).

Wenn ich mit dem Importer mit einem REST-Server sprechen möchte, dann brauche ich natürlich etwas anderes als wenn ich mit der Datenbank direkt spreche. Darum baut man das auch abstrakt und implementiert mit dem Zugriffs-Framework was einem in den Sinn kommt, oder man sich leisten kann oder welches da am besten ist.

[Bbommel]

Zitat:

Zitat von Schokohase (Beitrag 1423055)

Nun ja, zum Thema FireDAC, Enterprise, auf eine Komponente muss man sich einigen ...

Dazu hätte ich ein entschiedenes Nein.

Hmja. Wie abstrakt man auch immer irgendwelche Import-Geschichten macht, ob nun selbst gebastelt oder auch noch ein Framework dazu gekauft. Am Ende steht irgendwann die Komponente, die den eigentlichen Zugriff auf den MS SQL-Server machen soll.

Also: doch, auf irgendeine Komponente muss man sich da festlegen. Und die ist gesucht.

[MyRealName]

UniDAC geht auch auf Lazarus und Linux (und natürlich Android, iOS, MacOS), da bist zumindest von den Platformen her offen. Und wie schon gesagt, sind wohl die schnellsten :) Darauf kommt es ja beim import/export an. Wenn Du SDAC nimmst, dann bist von den Komponenten her auf MS SQL Server festgelegt und es gibt keine Azure Anbindung wie bei UniDAC. Und Geschwindigkeit ist wohl die gleiche, da UniDAC den code von SDac nutzt für seinen Provider

[rokli]

Ich benötige keine weiteren Client Kompos, wenn ich eine Software auf einem Ziel-System installiere.
Bei mir wird alles ins Ekxe kompiliert.