Fehler mit DBNavigator

[khh]

Ich habe jetzt mal probeweise anstatt der ZQuery eine ZTable verwendet.
Der Fehler ist identisch.
Ich geh mal davon aus, dass zu diesem Zeitpunkt die ID halt noch nicht zur Verfügung steht

[Sir Rufo]

Zitat von khh:

Ich geh mal davon aus, dass zu diesem Zeitpunkt die ID halt noch nicht zur Verfügung steht

Diesen philosophische Ansatz könntest du mit dem Debugger in eine fundierte Erkenntnis umwandeln.

[mkinzler]

Die ID existiert am Server aber wahrscheinlich nicht im Client.
Ich würde wieder den Query nehmen und im InsertSQL des Updateobjektes mir diese zurückgeben lassen

insert into ... returning ID into :id; und hoffen, dass Zeos das so unterstützt.
[Edit: Natürlich im InsertSQL nicht im UpdateSQL]

[khh]

Zitat von mkinzler:

Die ID existiert am Server aber wahrscheinlich nicht im Client.
Ich würde wieder den Query nehmen und im UpdateSQL des Updateobjektes mir diese zurückgeben lassen

insert into ... returning ID into :id; und hoffen, dass Zeos das so unterstützt.

ich danke, dir werd ich so ausprobieren

[mkinzler]

Ich hatte oben in der Schnelle etwas falsches geschrieben, Code gehört in InsertSQL

[p80286]

Zitat von khh:

Worin besteht eigentlich konkret der Unterschied zwischen Table und Query?

Eine Query enthält Daten, die über ein select-Statement aus einer Datenbank exportiert werden. Eine Table ist Teil einer DB.
Mit Select * from Irgendeinetable liefert Dir eine Query den Inhalt einer Table. Je nachdem wie Intelligent eine Komponente ist, kann sie eine Query wie eine Tabelle behandeln. Z.B. Updates erzeugen bzw. Durchführen.
Da beide nicht synonym sind und unterschiedliche Datenbanken sich unterschiedlich verhalten, verlasse ich mich im allgemeinen nicht auf Oberfächen, die z.B. automatisch Updates an die darunter liegende Datenbank weiterleiten.

Gruß
K-H

[mkinzler]

Bei einer TTable wird automatisch die Abfrage

Code:

select * from <Tabelle>;

verwendet. Bei der Verwendung eines Queries kannst Du das selber festlegen (nicht alle Felder, Daten aus mehreren Tabellen usw.)

[dataspider]

Das Verständnis für die Vergabe des PK ist Grundvoraussetzung!
Wenn im Before Insert Trigger steht:

Code:

  if (new.id is null) then
    new.id = gen_id(gen_adresse_id, 1);

ist erst mal alles fein.
Lässt man die Abfrage auf "is null" weg, kann das schon ein Problem sein!

Die Query - Komponenten bieten verschiedene Lösungen an.
Bei TIBQuery und auch anderen kann man den Generator - Name angeben.
Dann wird beim Post nach einem Insert die ID von der Anwendung und nicht vom Server erzeugt.
Dadurch kennt die Query den Wert der ID und kann diesen benutzen, ohne vorher eine Synchronisation mit dem Server durchführen zu müssen.
Hätte ich hier im Trigger die Zeile "if (new.id is null) then" weggelassen, hätte ich einen netten Effekt.
Der Server vergibt auch eine ID, die in der Regel 1 höher ist als die, die die Query jetzt weiter verwendet.

Wenn du also ein Update machst, wird er keinen Datensatz finden oder im schlimmsten Fall einen Datensatz updaten, den ein anderer gerade angelegt hat.

Seit FB 2.5 gibt es das RETURNING, welches von den meisten Komponenten unterstützt wird.
Die Einstellungen sind auch hier bei den unterschiedlichen Komponenten unterschiedlich gelöst.

Ich kenne die TZQuery nicht.
Also solltest du:

- Trigger prüfen
- nachsehen, ob man bei TZQuery den Namen des Generators irgendwo hinterlegen kann
- und das Ergebnis (wie Sir Rufo ja schon sagte) mit dem Debugger überprüfen.

Frank

[Perlsau]

Soweit mir bekannt, stellten frühere Versionen der Zeos-Komponenten lediglich unidirektionale Datenmengen bereit. Für die Bearbeitung eines selektierten Datensatzes in einem DB-Grid ist jedoch eine bidirektionale Datenmenge erforderlich. Wie das bei Zeos derzeit aussieht, vermag ich nicht zu sagen, da ich Zeos das letzte Mal wohl vor 5 Jahren verwendet hatte. In Lazarus- bzw. CodeTyphon setze ich die beiliegenden Ib-Komponenten ein, die bidirektional sind und eine Verbindung mit einer Firebird-Datenbank auf einfachste Weise ermöglichen.

Ergänzung:
Habe eben einen Thread im Delphi-Treff gefunden, der dasselbe Problem zur Grundlage hat.

[BadenPower]

Zitat von Sir Rufo:

Zitat von khh:

Ich geh mal davon aus, dass zu diesem Zeitpunkt die ID halt noch nicht zur Verfügung steht

Diesen philosophische Ansatz könntest du mit dem Debugger in eine fundierte Erkenntnis umwandeln.

Gleichzeitig könnte man noch die Komponente ZSQLMonitor in sein Projekt setzen.

Damit kann man elegant und ohne eine Zeile Code zu schreiben, prüfen, welche SQL-Statements an die Datenbank gesendet werden.