Zugriff mit FDConnection / FDQuery --> ODBC --> FireBird Daten Änderung nicht möglic

[fisipjm]

Hi,

ich hab mal wieder ein seltsames Anliegen, dass ich nicht verstehe und deshalb wahrscheinlich auch nicht lösen kann.
Ich greife aktuell dem Firebird ODBC Treiber auf eine Firebird Datenbank zu. Funktioniert!
Ich kann selecten nach Herzenslaune.
Jetzt versuche ich folgendes:
Ich rufe mit einem

Delphi-Quellcode:

FDQuery.open(Select * from Tabelle where Primaerschlüssel = 123)

den zu ändernden Tabellenwert auf. Ich ändere den Wert folgendermaßen:

Delphi-Quellcode:

FDQuery.edit;
FDQuery.FieldByName('Dummer_Slogan').asString:='Jama jaja Ypipi Ypipi Jey';
FDQuery.post;

Problem, ich bekomme die Meldung

Code:

[FireDAC][DApt]-400. Update-Anweisung updated [0] anstelle von [1] Datensatz. Mögliche Ursachen: Aktualisierungstabelle hat keinen Primärschlüssel oder Zeilenbezeichner, Datensatz wurde von einem anderen Benutzer geändert/gelöscht

Hab auch schon rausgefunden was ich in der Queryumstellen kann. Es gibt in dem FDQuery DesignTimeObjekt eine Option die lautet:

Code:

Optionen --> Eintragen von Änderungen --> Anzahl der aktualisierten Datensätze prüfen

Wenn ich das raus lasse bekomme ich keine Fehlermeldung mehr.
Jetzt meine Frage:
Wenn ich es raus lasse, habe ich signifikante Nachteile? Warum ist mein ODBC Treiber nicht in der Lage das abzufrühstücken? Und die Vielwichtiger Frage, wie kann ich das im Code definieren, bzw. geht das auch in der Connection?
Fragen über Fragen :-D Ich hoffe es gibt jemand der sich mit dem Thema schon mal außeinandersetzen musste und der mir einen kleinen Schups in die richtige Richtung geben kann :cyclops:

[Delphi.Narium]

Schau mal im ODBC-Treiber nach, ob er überhaupt lesen und schreiben zulässt.
Ebenso in den Optionen der Datenbankverbindung und/oder der Query.

Wenn Du das "Anzahl der aktualisierten Datensätze prüfen" rauslässt, bekommst Du keine Fehlermeldung mehr, erfährst aber vermutlich auch nicht, wenn kein Datensatz statt des erwarteten einen Datensatzes geändert wird (oder auch gaaaanz vieeele Datensätze :-(). Wäre das zielführend?

Statt Edit + Post könntest Du ja auch per SQL ein Update machen, wenn Du sowieso weißt, welcher Datensatz mit welchen Inhalten versorgt werden soll.

SQL-Code:

update Tabelle set Dummer_Slogan = :ParameterWert where Primaerschlüssel = :ParameterSchluessel

Im Quelltext dann noch die beiden Parameter befüllen und per ExecSQL an die Datenbank schicken.

Als Chromleiste das Ganze dann noch in 'ne Transaktion packen, dann ist im Fehlerfalle auch noch ein Rollback möglich, mit der Folge, dass sich die Datenbank dann in 'nem definierten Zustand befindet. Und nicht, wie bei unterdrückter Ergebnisüberprüfuung hoffentlich in einem definierten Zustand befinden könnte oder aber auch in einem Zustand der Form: "Nix genauses weiß man nicht." ;-)

[fisipjm]

Zitat:

Zitat von Delphi.Narium (Beitrag 1504559)

Schau mal im ODBC-Treiber nach, ob er überhaupt lesen und schreiben zulässt.
Ebenso in den Optionen der Datenbankverbindung und/oder der Query.

Ja ja, schreiben geht. Das ist ja der Witz, da aktuell keine Transaktionskontrolle drin ist, bekomm ich einen Fehler hab am Ende aber den wert trotzdem drin stehen.

Wenn ich mir nach dem Select die Struktur in der Query anschaue, dann sehe ich keinen Primärschlüssel, obwohl in der DB einer definiert ist. Könnte das das Problem sein? Wisst ihr wie ich herausfinden kann ob das ein ODBC oder ein FireDac thema ist?

Ich hab gerade erst alles umgeschrieben, es war vorher mit einem Update statement gelöst, aber das war nicht mehr Dynamisch genug und hat den Quellcode sehr schlecht lesbar gemacht. Ich würde gerne die edit/post Logik beibehlaten.

[Delphi.Narium]

Zuerst: Weder mit FireBird noch mit ODBC noch mit einer Kombination aus beidem (und dabei war/ist es egal, welche Datenbankkomponenten ich seitens Delphi verwende), hatte ich bisher Probleme. Es liegt für meine Begriffe grundsätzlich weder an dem einen, noch an dem anderen, allenfalls an der Art der Verwendung. Und die ist hier nicht näher beschrieben, so dass es unmöglich ist zu erkennen, wo das Problem liegen könnte.

Man muss bei der Konfiguration schon darauf achten, dass man nicht nur Lese- sondern auch Schreibrechte hat.

Die Edit-/Post-Variante ist die eher fehleranfällige. Letztlich muss auch bei deren Verwendung "irgendwo in der Datenbankschnittstelle" ein entsprechendes Update-Statement generiert werden, welches dann an die Datenbank geschickt und dort verarbeitet wird.

Hab' in einem meiner Programme auch so 'ne Schleife mit Edit+Post. Und wenn ich in der Monitoringtabelle von FireBird nachschaue, was da so passiert, sehe ich ein Select und eine ganze Reihe von Update-Statements.

Eine eher blöde Idee:

Dein Select und Edit/Post funktioniert beim ersten Mal (was Du an den geänderten Daten in der DB sehen kannst), aber in der weiteren Verarbeitung erkennt "irgendwerwieoderwas" in der Kommunikation zwischen Deinem Programm und der Datenbank, dass der Satz geändert wurde und weiß nicht, dass der Satz gerade von "irgendwerwieoderwas" geändert wurde und bemängelt die eigene Änderung als nicht erfolgreich. Wäre eher schräg, aber ist eventuell nicht auszuschließen.

Auch wenn Select + Update etwas aufwändiger zu programmieren ist, als Edit + Post, könnte das zusammen mit 'ner vernünftigen Transaktionsklammer durchaus die sinnvollere Alternative sein. Eventuell funktuionieren aber auch Edit + Post, wenn da 'ne Transaktionsklammer drum ist. Ohne sinnvolles Transaktionshandling ist das sowieso eher so 'ner Art Lottospiel.

Dann schau bitte mal hier, ab Du das eventuell was brauchbares findest: https://stackoverflow.com/questions/...ving-strangely

[Uwe Raabe]

Zitat:

Zitat von fisipjm (Beitrag 1504563)

Wenn ich mir nach dem Select die Struktur in der Query anschaue, dann sehe ich keinen Primärschlüssel, obwohl in der DB einer definiert ist.

Das ist definitiv zumindest ein Hinderungsgrund für das Update. Es gibt mindestens zwei Möglichkeiten das mit Bordmitteln zu lösen:

1. Du sorgst dafür, dass das Feld für den Primärschlüssel auch als solches definiert ist. Am Einfachsten legst du das Feld statisch an und setzt in dessen ProviderFlags das pfInKey auf True. Damit die übrigen Felder dynamisch angelegt werden, musst du noch in der Query in FieldOptions das AutoCreateMode auf acCombineAlways setzen.

2. Du änderst in der Query in den UpdateOptions den UpdateMode auf upWhereAll.