![]() |
AW: Fehler mit DBNavigator
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 :-( |
AW: Fehler mit DBNavigator
Zitat:
|
AW: Fehler mit DBNavigator
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:
und hoffen, dass Zeos das so unterstützt.
insert into ... returning ID into :id;
[Edit: Natürlich im InsertSQL nicht im UpdateSQL] |
AW: Fehler mit DBNavigator
Zitat:
|
AW: Fehler mit DBNavigator
Ich hatte oben in der Schnelle etwas falsches geschrieben, Code gehört in InsertSQL
|
AW: Fehler mit DBNavigator
Zitat:
Mit
SQL-Code:
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.
Select * from Irgendeinetable
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 |
AW: Fehler mit DBNavigator
Bei einer TTable wird automatisch die Abfrage
Code:
verwendet. Bei der Verwendung eines Queries kannst Du das selber festlegen (nicht alle Felder, Daten aus mehreren Tabellen usw.)
select * from <Tabelle>;
|
AW: Fehler mit DBNavigator
Das Verständnis für die Vergabe des PK ist Grundvoraussetzung!
Wenn im Before Insert Trigger steht:
Code:
ist erst mal alles fein.
if (new.id is null) then
new.id = gen_id(gen_adresse_id, 1); 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 |
AW: Fehler mit DBNavigator
Soweit mir bekannt, stellten frühere Versionen der Zeos-Komponenten lediglich
![]() ![]() Ergänzung: Habe eben einen ![]() |
AW: Fehler mit DBNavigator
Zitat:
Damit kann man elegant und ohne eine Zeile Code zu schreiben, prüfen, welche SQL-Statements an die Datenbank gesendet werden. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:20 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz