Umstellung IB-Express auf ADO (dbGo)

[Bernhard Geyer]

Zitat:

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 :gruebel:) 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.

[Peinhard]

Das ist alles absolut nicht von der Hand zu weisen, auch der Verzicht auf DB-Komponenten nicht. Es hängt doch aber auch daran

- wie umfangreich das Projekt ist

- wie der geplante weitere 'Lebenszyklus' aussieht

- und last not least wieviel Zeit man dafür hat bzw bekommt

Daß zuwenig Zeit jetzt dann später noch viel mehr Zeit kosten kann, ist natürlich ebenfalls richtig - nützt aber auch nichts, wenn man in der Zwischenzeit evt 'vom Markt' verschwunden ist oder sich mit seinen Argumenten etwelchen 'Vorturnern' gegenüber nicht durchsetzen kann. Versuchen sollte man es aber, abhängig davon, wie es mit den beiden ersten Punkten aussieht.

[Neptun]

Hallo zusammen.

Vielen Dank erstmal für eure Hilfe.

Das Problem ist dasgleiche wie immer. Es existieren bereits umfangreiche Strukturen und es
darf nur so_und_solange dauern.

Zum Glück war ich schon so schlau die IB-Express Komponenten nicht direkt in meine Anwendung
(also sprich auf das Form ziehen) zu integrieren, sondern eine API aus den Komponenten zu
bauen.

Daher geht es jetzt schneller, Koponenten zu benutzen, die von TDataset abgeleitet sind. Da ADO
sowohl auf die DBS von MS, Oracle und über ODBC noch auf andere zugreifen kann, habe ich
mich halt so entschieden.

Datensensitive Komponenten, wie TDBGrid verwende ich so gut wie kaum und den Rest hab ich auch
ganz schnell rausgeschmissen.

Im Augenblick erzeuge ich unter Interbase den Primärschlüssel mit einer Trigger/Generator
Kombination. Mit Generator TIBDataSet.GeneratorField bekomme ich den Wert zurück in das
TDataset.

Also vielen Dank erstmal und schöne Grüße :hi:
Matthias