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.