Hallo Volker,
wie ich schon in einem vorherigen Post geschrieben habe, habe ich
den fbird_commit inzwischen nach der von Dir vorgeschlagenen
2. Syntax, was insoweit erfolgreich war, dass dieser keinen Error
mehr produziert.
fbird_commit($link_or_trans_identifier);
Wenn ich den SELECT absetze erhält dieser z.B. die "Resource id #53" und ich
erhalte als "result identifier" die "Resource id #58" zurück.
So ist es auch unter
https://www.php.net/manual/en/function.ibase-query.php beschrieben.
Mit dem Result-Identifier "Resource id #58" starte ich nun meine While-Schleife mit dem
fbird_fetch_assoc("Resource id #58").
Der 1. Datensatz wird dann auch noch von der While-Schleife korrekt ausgeliefert.
Innerhalb der While-Schleife setze ich ein vorher als Selections-Kriterium gesetztes
Feld wieder per Update auf 0;
Das mache ich häufig und das funktioniert in Regel auch sehr gut und problemlos,
solange ich jedenfalls nach einem Update oder Insert keinen fbird_commit($link_or_trans_identifier);
absetze.
Setze ich jedoch nach dem Update einen fbird_commit("Resource id #53"); dann kommt
halt die Fehler-Meldung, was wohl bedeutet, dass mit dem Result-Identifier "Resource id #58"
auch etwas passiert und nicht nur mit der #53.
Jetzt könnte man als Erklärung vermuten, dass die "Resource id #58" so als eine Art "verwandte"
Child-ResourceID von der #53 mit-commited wird.
Dagegen spricht allerdings die Tatsache, dass ich in dieser While-Schleife noch so Einiges mehr
mache, z.B. noch 1 - 3 Select's auf andere Tabellen absetze und jeder dieser Selects immer
wieder dieSELBE "Resource id #53" erhält, also die theoretisch denkbare "Verwandschaft" zur
"Resource id #58" von FB selbst schon lange mehrfach wieder gekappt wurde.
Das ist für mich schon alles recht merkwürdig und nicht logisch bzw. kausal.