Fehler mit DBNavigator

[khh]

Hallo zusammen,

ich habe einen TDBNavigator mit einem Dataset verbunden.
Funktioniert bis auf eine, leider wichtige, Kleinigkeit.
Vorgehensweise:
1. ich schalte über den entsprechenden Button in der Insert-Mode
2. ich gebe Daten in die TDBEdit-Felder ein
3. ich betätige den Post-Button
4. ich schalte nochmals in den edit-Mode ohne den DS vorher verlassen zu haben.
5. ich ändere die Daten
6. Betätigung des Post-Button
jetzt krachts, ich bekomme eine EZSQLException.
0 Records updated, Only one record should have been updated.

Bug oder Feature ? ;-)

[khh]

kann das jemand nachvollziehen ?

[mkinzler]

Welche Komponente (Table, Query)?

[khh]

Zitat:

Zitat von mkinzler (Beitrag 1309805)

Welche Komponente (Table, Query)?

TZQuery von ZEOS

[mkinzler]

Wie sieht das Updatestatement aus? Funktioniert dies in einem abweichendem Szenario?

[khh]

was meinst du mit Updatestatement?

Es gibt lediglich die Abfrage-Query die mit dem TDatasource verbunden ist.
Ich überlege gerade ob es sinnvoller ist einen ZTable zu verwenden( die benutze ich sonst eigentlich nie), da ja eh alle Felder abgefragt werden.
Worin besteht eigentlich konkret der Unterschied zwischen Table und Query?
EDIT; ich habe mir bisher meine Speicherroutinen immer selbst "gebaut", jetzt wollte ich mal was "fertiges" nehmen :-(

[mkinzler]

Möglicherweise erzeugt TZQuery die restlichen Abfargen selbstständig wie TZTable .
Durch die Verwendung eines Updateobjektes ( TZUpdateSQL) kann man diese aber selber festlegen.

Hat die Tabelle einen PK?

[khh]

ja, der Primary-Key ist die ID die per Generator und Trigger gesetzt wird

[mkinzler]

Ich würrde die Statements manuell festlegen

[khh]

werd ich versuchen, ich danke dir

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

Zitat von khh (Beitrag 1309845)

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

SQL-Code:

insert into ... returning ID into :id;

und hoffen, dass Zeos das so unterstützt.
[Edit: Natürlich im InsertSQL nicht im UpdateSQL]

[khh]

Zitat:

Zitat von mkinzler (Beitrag 1309858)

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

SQL-Code:

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:

Zitat von khh (Beitrag 1309828)

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

SQL-Code:

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:

Zitat von Sir Rufo (Beitrag 1309849)

Zitat:

Zitat von khh (Beitrag 1309845)

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.