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" .

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 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 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 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 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")
);

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 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 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")
);

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 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 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