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

[jsheyer]

FireDAC ist doch das ehemalige AnyDAC was nicht von DevArt war/ist oder irre ich mich da??

[mkinzler]

Der Entwickler von AnyDAC war ein Entwickler bei CoreLabs (heute DevArt) und hat nach seinen Abschied DA-Soft gegründet.

[p80286]

Nach deiner Beschreibung sollte eigentlich nur ADO.Query.xx durch NeueKomponente.query.xx ersetzt werden.
Gut auch die Connection, aber da wahrscheinlich nur eine Procedure betroffen. Wäre es da niht vollkommen egal welche du nutzt? Du müßtest Keine Rücksicht auf DBGrid und Konsorten nehmen, ich würde da keine OneForAll-Komponente nuzen.

Gruß
K-H

[Schokohase]

Wenn man da jetzt eh dran rum bauen muss, dann sollte man auch die Chance nutzen und es gleich vernünftig umbauen.

Keine direkten Abhängigkeiten mehr von den Zugriffskomponenten.
(scheint selbst 2019 keine Selbstverständlichkeit zu sein)

[Bbommel]

Danke für eure bisherigen Rückmeldungen.

Weil ja doch hier und da mal FireDAC erwähnt wurde: mit einer Enterprise-Lizenz wäre es ja auch kein Problem, das einzusetzen. Aber wenn ich das bei einem ersten (allerdings relativ schnellen) Test richtig gesehen habe, setzt FireDAC ja irgendwelche Client-Komponenten voraus, die man vorher installieren müsste, richtig? Das wäre für mich schon ein recht starkes Argument für DevArt.

@p80286: Genau, es gibt keine Abhängigkeiten zu irgendwelchen visuellen Komponenten, insofern ist es tatsächlich relativ egal - aber trotzdem muss ich mich ja letztlich für eine bestimmte Komponente entscheiden.

@Schokohase: Ich hätte wetten können, dass von irgendwem dieser Hinweis kommt. Ja, viele Import-Routinen von mir sind schon mit einer neutralen Importer-Klasse umgesetzt und dort ist die Ergänzung einer weiteren oder der Austausch einer existierenden DB-Komponente natürlich besonders leicht. Die übrigen Import-Routinen, die bisher noch direkt über die ADOQuery zugreifen, würde ich bei dieser Gelegenheit wahrscheinlich auch entsprechend umbauen - wäre dann jetzt etwas mehr Arbeit, hat sich aber den existierenden umgestellten Routinen schon mehrfach gelohnt. Aber letztlich war das ja nicht die Kernfrage, sondern die Suche nach der Komponente, die letztlich den eigentlichen Zugriff machen soll.

[MyRealName]

Zu deiner Frage mit Azure, UniDAC kann das wohl laut Webseite. SDAC sicherlich nicht.
Ich nutze seit Jahren UniDAC und bin sehr zufrieden, Performance mässig sollen die wohl die Besten sein.

[rokli]

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

[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 von Schokohase:

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.