TOPIC:

Ich habe eine VO 2.8 App, welche Daten in diverse MySQL Tabellen nicht selbst sondern über ein PHP restAPI speichert. VO erhält dann das Ergebnis oder den Fehler als JSON String retour. Dazu benutze ich Norberts GetDocumentByGetOrPost. Datensätze werden eingefügt (POST), upgedatet (PUT), gelöscht (DELETE) und ausgelesen (GET). Einfügen, update und löschen funktioniert tadellos, kontrollierbar durch phpMyAdmin.

Beim Auslesen funktioniert allerdings nur das Auslesen eines einzelnen Datensatzes (select * from tbl where id = ?). Wenn ich aber alle Datensätze haben will (select * from tbl), dann erhalte ich immer den Stand zurück, wie er zum Zeitpunkt des VO Programmstarts war, alle danach gemachten updates und deletes scheinen nicht auf (nur eingefügte Sätze scheinen auf)!

An der PHP Routine kanns nicht liegen, da ich die korrekten Daten erhalte, wenn ich das PHP restAPI direkt im Browser oder mit anderen Programmen (z.B. Postman) aufrufe. Ausserdem bringt VO die richtigen Daten, wenn ich das VO Programm beende und neu starte. Es sieht irgendwie so aus, als ob VO oder die cHttp Klasse die Abfrage und das Ergebnis cachen würde. Ein Aufruf des Garbage Collectors hat nicht geholfen, die cHttp Klasse wird ordnungsgemäß mit Axit beendet.

Gibt es irgendetwas, das ich machen kann, was einem Beenden+Neustart der VO App entspricht, ohne die App tatsächlich neu zu starten?

Hallo Franz,
kann es sein, dass auf der PHP-Seite kein Commit gemacht wird?
Wolfgang

Hallo Wolfgang,
MySQL steht defaultmäßig auf AutoCommit.
Ich habs auch schon mit TRANSACTION und COMMIT versucht, ändert nichts.
Außerdem zeigt ja nur die VO App die alten Werte, Aufrufe mit anderen Programmen zeigen die korrekten Daten.
Wenn ich die VO App beende, neu starte und die Abfrage nochmals mache, bekomme ich auch hier die aktuellen Werte.

Hallo Franz,
das ist sehr komisch....wenn der Client cachen würde (also die VO-Applikation) würdest Du auch neue Sätze nicht bekommen.
Also muss das Problem serverseitig liegen.
Wolfgang

Hallo Wolfgang,
das kann ich mir eigentlich nicht vorstellen, zumindest nicht im PHP restAPI:

• andere Programme, welche das restAPI aufrufen, bringen die aktuellen Daten
• VO bringt bei Aufruf eines einzelnen Datensatzes (select * from tbl where id=?) auch die richtigen Daten, nur bei Aufruf aller Daten (select * from tbl) ohne where kommen die alten Inhalte daher
• ein Beenden/Neustart der VO App bringt auch die aktuellen Daten

Und noch eins ist mir dabei aufgefallen:
Wenn ich im PHP restAPI einen Syntaxfehler einbaue, dann bekomme ich die Fehlermeldung aus PHP an VO retour. Bessere ich den Fehler im PHP restAPI aus und starte die Abfrage erneut, ohne VO zu beenden und neu zu starten, bekomme ich trotzdem noch immer die Fehlermeldung, obwohl der Fehler ausgebessert wurde! Auch hier wird erst das korrigierte PHP restAPI verwendet, wenn ich die VO App beende und neu starte! Wer bezieht woher noch immer den alten PHP Code???

Hallo Franz,
dann kann es höchstens noch sein, dass ein Cache-Header gesetzt ist und die WinINet-Klasse die Daten cachen.
Dann sollte eine Wiederholung des "Select * from tbl" aber immer dieselben Daten bringen, und nicht neue Sätze zusätzlich.
Siehe hier:
learn.microsoft.com/de-de/troubleshoot/d...w-to-prevent-caching
oder das hier:
learn.microsoft.com/de-de/troubleshoot/d...ver-local-ip-address
Wolfgang

Hallo Wolfgang,
ich habe die Cache Statements in den Header eingebaut, hat aber nichts bewirkt!
Das Komische beim GET:

• Wenn ich einen einzelnen Datensatz abrufe, bekomme ich die aktuellen Werte
• Wenn ich alle Werte abrufe (ohne Where Bedingung) erhalte ich die alten Werte

Und das, obwohl die PHP Routine für einzelne und alle Datensätze die gleiche ist und sich nur in der Where Bedingung des Select Statements unterscheidet!
Was auch noch auffällt: Wenn ich einen Insert und einen Update hintereinander mache und dann alle Datensätze anzeige, dann sehe ich den eingefügten Satz korrekt, der upgedatete enthält aber die alten Werte.

Ich wünsche allen Lesern dieses Forums ein frohes Weihnachtsfest und ein gesundes und erfolgreiches Neues Jahr 2023!

Ich habe nun testweise das select Statement im restAPI fix aufgeändert. Somit ist die Routine im restAPI die gleiche, egal ob alle Datensätze gelistet oder nur 1 Datensatz abgerufen wird, damit kanns am restAPI nicht liegen.

Der einzige Unterschied ist in VO beim Aufruf des restAPI über GetDocumentByGetOrPost:

• /BMTest/unity.php -> für alle Daten funktioniert nicht
• /BMTest/unity.php/0 -> für alle Daten funktioniert nicht
• /BMTest/unity.php/3 -> für Datensatz mit id 3 funktioniert

Ich habe keine Ahnung was bei den ersten beiden Aufrufen in der cHttp Klasse nicht funktioniert!

cHttp ist doch als Source im SDK - kannst Du da nicht reindebuggen?

Ich habe inzwischen Folgendes festgestellt:
Normalerweise kommt als ResponseHeaderImmer wenn beim GET alte Werte kommen, dann fehlen die beiden Zeilen Date + Server! Beim ersten GET Aufruf kommen die richtigen Werte, dann ein Update, ab dann geht ein GET Aufruf nicht mehr zum Server sondern holt sich das Ergebnis vom ersten Aufruf irgend woher (Write einer Textdatei im restAPI erzeugt nur beim ersten Aufruf ein File).

Daraufhin habe ich den GET Aufruf direkt über cHttp und nicht über Norberts GetDocumentByGetOrPost gemacht:Damit funktionierts nun, also muß die Ursache des Problems irgendwo im GetDocumentByGetOrPost liegen.
Ich habe diese Routine schon durchgetestet, finde aber nichts.

Der Schuldige bei der Sache ist der Aufruf von HttpSendRequest, ich habe ihn auch schon gegen SELF:SendRequest ausgetauscht, mit gleichem Fehler. Ab dem 2. Aufruf geht der Aufruf nicht mehr zum Server sondern liefert die Daten anscheinend aus einem Cache, deshalb fehlen auch die beiden Zeilen Date: und Server: im Header.