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

[fisipjm]

Zitat von 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.

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 von fisipjm:

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.