Umstellung IB-Express auf ADO (dbGo)

[Neptun]

Hallo zusammen.

Ich bin diesem Forum neu, also erstmal einen heißen (30°C) "Guten Morgen Gruß"
aus dem schönen "Rheinhessischen Hügelland" :hi:.

Meine Arbeitsumgebung:
- Windows XP Prof. SP2
- Borland Developer Studio (Delphi) (Update 2)
- Interbase 7.1

Und nun zu meinem Problem.
Ich greife auf Tabellen mit SQL-Befehlen zu, indem ich eine Datenbankverbindung
mit TIBDatabase herstelle, damit eine Instanz von TIBDataSet verbinde und
mit dem TIBDataSet eine Transaktion TIBTransaction verbinde.

Dann werden die SLQ-Anweisungen für SELECT, UPDATE und INSERT gesetzt, wie z.B.:

Code:

IbDataSet.SelectSQL.Text  := 'SELECT * FROM ksc_user';
IbDataSet.RefreshSQL.Text := 'SELECT * FROM ksc_user WHERE id_user=:id_user';
IbDataSet.InsertSQL.Text  := 'INSERT INTO ksc_user (id_user, username, pwd, fullname, rights) VALUES(:id_user, :username, :pwd, :fullname, :rights)';
IbDataSet.ModifySQL.Text  := 'UPDATE ksc_user SET username=:username, pwd=:pwd, fullname=:fullname, rights=:rights WHERE id_user=:old_id_user';
IbDataSet.DeleteSQL.Text  := 'DELETE FROM ksc_user WHERE id_user=:old_id_user';

Dann kann ich die Datenmenge öffnen, Daten ändern und speichern.

Code:

IbDataSet.Open;
IbDataSet.Edit;
IbDataSet.FieldValues['username'] := 'Hans';
IbDataSet.Post;
IbDataSet.CommitRetaining;

Wenn ich an die TIBDataSet noch eine TDataSource hänge und daran ein TDBGrid, dann kann ich in dem Grid
alle Änderungen ausführen wie Einfügen, Ändern und Löschen von Einträgen.

Nun möchte ich das Ganze auf die ADO Komponenten (dbGo) umstellen.
Hier kann ich nun die SELECT Abfrage einfügen (CommandText), aber sonst nichts.

Wie kann ich nun Änderungen speichern ?

Irgendwo muss ich ja auch die DELETE und INSERT Anweisungen angeben können.

Ich hab da keine Idee wie das Gehen kann.

Über Umwege (mit separaten TADOCommand) kriege ich das schon hin, aber nicht so elegant wie mit
den IB-Express Komponenten.

Kennt jemand von euch eine Lösung ?

Vielen Dank und viele Grüße
Matthias

[Bernhard Geyer]

Und wieso willst Du auf ADO umstellen? Für Interbase sind noch native Komponenten besser als über ADO und evtl. noch ODBC zu gehen.

[Peinhard]

TADODataset.CommandText nimmt weit mehr auf als nur SELECT-Befehle, und außerdem gibt es ja auch noch zB TADOQuery mit der gewohnten SQL-property und den Befehlen Open (wenn eine Datenmenge erwartet wird) bzw ExecSQL (wenn keine erwartet wird, wie zB bei Datenmanipulationsbefehlen wie INSERT, UPDATE etc), eine Unterscheidung in verschiedene SQL-properties gibt es allerdings nicht. Es gibt TADOStoredProc für Stored Procedures, Transaktionen verwaltet die TADOConnection selbst. Kurzer Rede noch kürzerer Sinn: du kannst alles machen, was du bislang auch machen konntest... der Vorteil ist die Möglichkeit der leichteren Migration auf andere DBMS, wofür man allerdings auf server-spezifische Features verzichten sollte. Und da liegen eben auch gleich wieder die Nachteile...

peinhard

[Bernhard Geyer]

Zitat:

Zitat von Peinhard

... der Vorteil ist die Möglichkeit der leichteren Migration auf andere DBMS, wofür man allerdings auf server-spezifische Features verzichten sollte.

Nicht nur das. Jede Datenbank hat unterschiede in der SQL-Syntax wenn man mehr als ein simples SELECT * FROM MyTable absetzt. Deshalb sag ich immer: Für jede DB die beste Komponenten nehmen und den DB-Zugriff mittels Bridge-Pattern kapseln. Aber es wird etwas Off-Topic ...

[Neptun]

Vielen Dank für eure schnellen Antworten.

Hallo Bernhard.
Weil ich dann über die "OLE DB Provider" auf Datenbanken wie MS-SQL-Server und Oracel zugreifen kann.
Über den "OLE DB ODBC" Provider komme ich dann auch wieder auf Interbase.


Hallo Peinhard.
Wie man mit den ADO Komponenten auch INSERT und UPDATE Befehle absetzen kann weiss ich.
Wenn du dir aber die Beispiele von mir ansiehst wirst du sehen, dass man mit einem TIBDataset alles
gleichzeitig machen kann. Deshalb kann man in einem angekoppelten DBGrid auch alle Aktionen ausführen.
Genau darum gehts, wie kann ich ein DBGrid an die ADO Komponenten koppeln und im Grid Einfügen, Ändern
und Löschen.

Viele Grüße
Matthias

[Peinhard]

Zitat:

Zitat von Neptun

Wie man mit den ADO Komponenten auch INSERT und UPDATE Befehle absetzen kann weiss ich.
Wenn du dir aber die Beispiele von mir ansiehst wirst du sehen, dass man mit einem TIBDataset alles
gleichzeitig machen kann. Deshalb kann man in einem angekoppelten DBGrid auch alle Aktionen ausführen.
Genau darum gehts, wie kann ich ein DBGrid an die ADO Komponenten koppeln und im Grid Einfügen, Ändern
und Löschen.

Genauso wie mit deinem Beispielcode auch: Open, Edit, Feldwerte zuweisen, Post etc. Allerdings hast du keine direkte Kontrolle über die tatsächlich abgesetzten SQL-Befehle mehr, von Einstellung wie moMarshalAll bzw moMarshalModifiedOnly abgesehen, den Rest macht der 'Treiber'. Also kann man sich - zB mit einem Dataset.Delete, das auf einen Join losgelassen wird - gelegentlich auch mal nett in den Fuß schießen. Da muß man dann schon gelegentlich eingreifen und zB das automatische Delete in einem Grid abfangen und selbst implementieren, aber iA ist es schon ziemlich 'straightforward'.

Diese spezielle Konstruktion der IB-Komponenten war mir allerdings wirklich nicht bekannt - und ich find' sie schon charmant...

peinhard

[Bernhard Geyer]

Zitat:

Zitat von Neptun

Weil ich dann über die "OLE DB Provider" auf Datenbanken wie MS-SQL-Server und Oracel zugreifen kann.
Über den "OLE DB ODBC" Provider komme ich dann auch wieder auf Interbase.

Und wirst scheitern wenn du in die Gemeinheiten der SQL-Unterschiede kommst und trotzdem für jede DB eine eigene Implementierung benötigst. Und da du dann keine saubere Trennung DB-Zugriff <-> Rest hast wirst Du auch mit jedem Versionsunterschied (Oracle ist hier sehr krativ mit jedem Servicpack neue inkompatiblitäten einzubauen) mehr Chaos im Code verursachen.

Unsere Oracle-Eigenheiten-Implementierung ist auf ca. 1600 Quellcodezeilen komprimiert bei einer Exe mit 1. Mio-Quellcodezeilen.

Und nochwas: Ich hoffe du willst bei Oracle nicht den MS ADO-Provider nehmen? Dann kannst Du dir gleich in den Kopf schießen da dies eine Machbarkeitsstudie von MS ist das man mit ADO auch mit Oracle arbeiten kannst. Du wirst auf jedenfall einen Provider von Oracle installieren müssen.

[Peinhard]

Zitat:

Zitat von Bernhard Geyer

Und wirst scheitern wenn du in die Gemeinheiten der SQL-Unterschiede kommst und trotzdem für jede DB eine eigene Implementierung benötigst. Und da du dann keine saubere Trennung DB-Zugriff <-> Rest hast wirst Du auch mit jedem Versionsunterschied (Oracle ist hier sehr krativ mit jedem Servicpack neue inkompatiblitäten einzubauen) mehr Chaos im Code verursachen.

Unsere Oracle-Eigenheiten-Implementierung ist auf ca. 1600 Quellcodezeilen komprimiert bei einer Exe mit 1. Mio-Quellcodezeilen.

Ja, das stimmt leider, und ich bin froh, zumindest Oracle bislang nicht 'bedienen' zu müssen. Wenn MS schon 'krank' ist... und mehr noch gilt das anscheinend für die jeweiligen 'Herrchen'.

Für den 'Rest' reicht - toitoitoi - bislang bedingte Compilierung mit verschiedenen Statements in einer Konstanten-Datei. Leider ist SQL eben längst nicht (mehr) 'Der Standard' - Mr Date sendet grimmige Grüße. Wäre vielleicht nicht schlecht, wenn es wirklich ein Gremium gäbe, daß die 'Macht' hätte, DBMS zu 'zertifizieren' und Lizenzen für SQL zu vergeben - oder eben auch nicht.

peinhard

[Neptun]

Hallo Peinhard.

Sorry, aber das funktioniert nicht.
Woher soll die Komponente/Treiber wissen wie er die UPDATE, INSERT oder DELETE Anweisungen
generieren soll, wenn er nur die SELECT Anweisung kennt.

Bei folgender Tabellenstruktur kann ich mir das noch vorstellen, da es einen Primärschlüssel
gibt.

SQL-Code:

CREATE TABLE "KSC_USER"
(
  "ID_USER"   INTEGER NOT NULL,
  "USERNAME"  VARCHAR(32) NOT NULL,
  "PWD"       VARCHAR(32) NOT NULL,
  "FULLNAME"  VARCHAR(64) NOT NULL,
  "RIGHTS"    INTEGER DEFAULT 0,
  PRIMARY KEY ("ID_USER")
);

SQL-Code:

SELECT * from KSC_USER

Allerdings gibt es keine Information, wie bei einem INSERT der Primärschlüssel
ID_USER erzeugt werden soll.

Ich versuche im Moment auf diese Tabelle zuzugreifen. Über ADO und ODBC auf Interbase
und bekomme dabei einen Fehler beim Schreiben der Änderungen mit UpdateBatch().

Das ist das Problem, dass ich im Moment lösen muss.

Um das Problem mit den herstellerspezifischen Unterschieden muss ich mich später kümmern.
Im Augenblick lautet meine Aufgabenstellung: "Umstieg von Interbase auf MS-SQL-Server 2005".

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.

Gruß
Matthias

[Peinhard]

Zitat:

Zitat von Neptun

Sorry, aber das funktioniert nicht.
Woher soll die Komponente/Treiber wissen wie er die UPDATE, INSERT oder DELETE Anweisungen
generieren soll, wenn er nur die SELECT Anweisung kennt.

Er versucht es aber tapfer, und meistens haut's auch hin - Ausnahmen hatte ich ja schon eine genannt. Und die Fehlermeldung 'Die gesuchte Reihe konnte nicht gefunden werden, da sich inzwischen mehrere Werte...' osä etc wird man auch bald 'schätzen' lernen... Primärschlüssel sind sozusagen 'Pflicht'.

Zitat:

Zitat von Neptun

Bei folgender Tabellenstruktur kann ich mir das noch vorstellen, da es einen Primärschlüssel gibt.

SQL-Code:

CREATE TABLE "KSC_USER"
(
  "ID_USER"   INTEGER NOT NULL,
  "USERNAME"  VARCHAR(32) NOT NULL,
  "PWD"       VARCHAR(32) NOT NULL,
  "FULLNAME"  VARCHAR(64) NOT NULL,
  "RIGHTS"    INTEGER DEFAULT 0,
  PRIMARY KEY ("ID_USER")
);

SQL-Code:

SELECT * from KSC_USER

Allerdings gibt es keine Information, wie bei einem INSERT der Primärschlüssel
ID_USER erzeugt werden soll.

Entweder AutoInc (bei MS IDENTITY) oder selbst erzeugt, zB mit einer entsprechenden Werte-Tabelle und einer StoredProc (nicht unbedingt mit MAX()-Abfragen ;). Deine eingestellten Beispiele verraten aber auch nichts darüber, wie das momentan gelöst ist - oder is es doch einfach zu heiß...?

Zitat:

Zitat von Neptun

Ich versuche im Moment auf diese Tabelle zuzugreifen. Über ADO und ODBC auf Interbase
und bekomme dabei einen Fehler beim Schreiben der Änderungen mit UpdateBatch().

Das ist das Problem, dass ich im Moment lösen muss.

Ich hab leider keinen Zugriff auf IB hier, aber ein bisschen mehr Info könnt' net schaden.

Zitat:

Zitat von Neptun

Um das Problem mit den herstellerspezifischen Unterschieden muss ich mich später kümmern.
Im Augenblick lautet meine Aufgabenstellung: "Umstieg von Interbase auf MS-SQL-Server 2005".

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.

Ich fühle mit dir... in einem meiner Lieblings-Dilberts schlägt der Chef vor, eine SQL-Datenbank anzuschaffen, und Dilbert fragt erst sich, ob der da wirklich weiß wovon er redet oder ob er nur wieder was gelesen hat, und dann ihn, welche Farbe denn die DB haben sollte. Antwort: 'Ich glaube Flieder hat am meisten RAM'... ok, etwas am Thema vorbei, aber wohl nicht allzuweit.

peinhard

[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