Umstellung IB-Express auf ADO (dbGo)

[Bernhard Geyer]

Zitat von Neptun:

Da ich meine Vorturner aber kenne, wird es irgendwann heissen: "..wir hatten doch schon mal mit Interbase.."
oder "..wir haben da einen, der hat schon ein Oracle Cluster..".
Also versuche ich über die ADO Komponenten die entsprechenden Weichen zu stellen.

Und wiesos meinst du das man bei ADO.NET (neben der kompletten Umstellung auf (normalerweise) nicht verbundene Datenmengen auch wieder für jede Datenbank eigene Zugriffsklassen hat ähnlich wie man bei der VCL mit auf TDataset basierende native DB-Komponenten besitzt und nicht wie unter ADO.Win32 alles per Connection-String "lößt". Man hat gemerkt das man damit die SQL-Unterschiede nicht in den Griff bekommt. Also ist es sinnvoller für jede DB die besten Zugriffskomponenten zu verwenden und darüber einen DB-Neutralen Zugriffslayer. Frameworks wie NHypernate (Ist das Richtig geschrieben ) oder das ECO-Framework machen das. Also wieso gehst Du den Weg zurück und begiebst dich in eine Sackgasse.

Wenn Du die Aufgabe "Umstieg von Interbase auf MS-SQL-Server 2005" hast mach das lieber in folgenden Schritten:

1, Überleg dir eine DB-Neutrale Zugriffsschicht (Bridge Pattern oder ähnliches). Ich würde dir sogar empfehlen keine DB-Sensitiven Controls mehr zu verwenden.
2, Stelle deine Interbase-Zugriffe auf diese Zugriffsschicht
3, Implementier als alternative den Zugriff auf den MS-SQL-Server 2005

Du hast damit folgende Vorteile:

1, Bessere Trennung von Anwendungslogik <-> Datenspeicherung (DB)
2, Keine Abhänigkeit von einem DB-Hersteller (Anti-Pattern: Ventor Lock In).
3, Bessere Erweiterbarkeit (Was machst Du wenn in 1 Jahr ein großer Kunde kommt und unbedingt DB2 will ohne einen ODBC/ADO-Treiber zu installieren haben will?)

Nachteil:

Mehr Aufwand.