Stored Procedure wird nicht vollständig ausgeführt

Lieber Support,
ich möchte mit folgender Stored Procedure Daten aus einer Tabelle lesen und in einem Textadapter ausgeben.
Dies funktioniert auch erst einmal soweit.
Gleichzeitig soll aber die Procedure das (Mess-)Datum des letzten Exports in eine weitere Tabelle schreiben.
Dieser Teil der Stored Procedure wird aber nicht ausgeführt, das Datum wird dort nicht aktualisiert. 
INSERT,DELETE und UPDATE sind im MySQL-Adpater "true"!.
Wenn ich die Stored Procedure ohne FlowHeater ausführe, funktioniert alles wie erwartet.
Woran hängt es, dass die  Stored Procedure bzw. der UPDATE-Teil nicht vollständig ausgeführt wird?
Die Stored Procedure : 

BEGIN

DECLARE lastdata DATETIME;
DECLARE maxdate DATETIME;

SELECT lastdate FROM export_state WHERE ID=150 INTO lastdata; #Statustabelle
SELECT MAX(messzeit) FROM dt_st01 INTO maxdate; #Datentabelle

SELECT t1.messzeit AS 'Messzeit', 
SUM(CASE WHEN t1.kanal_id=150 THEN messwert ELSE NULL END) AS 'MW01',
SUM(CASE WHEN t1.kanal_id=114 THEN messwert ELSE NULL END) AS 'MW02'
FROM dt_st01 t1 
WHERE t1.messzeit>lastdata
GROUP BY messzeit
ORDER BY messzeit ASC;

UPDATE export_state SET lastdate = maxdate WHERE ID=150;

END



Vielen Dank 
 

Hallo Herr Römermann,

ich kann erstmal kein Problem mit der MySQL „Stored Procedure“ erkennen, habe aber eine Vermutung.

Wenn Sie die Definition nur im „Testmodus“ laufen lassen führt der MySQL Adapter in den Standardeinstellungen am Ende wieder ein „Rollback“ der Datenbank Transaktion durch.

Versuchen Sie bitte mal die Definition nicht im „Testmodus“ laufen zu lassen.

Hallo liebes Support-Team,
die UPDATE-Anweisung wird auch nicht ausgeführt, wenn der Testmodus ausgeschaltet ist.
Die fhd-Datei hab ich mal beigefügt, falls es hilft.
Ich fürchte eher, dass INSERT-/UPDATE-Befehle im READ-Adapter ignoriert werden, was in diesem Falle Schade wäre.
Kann dies sein ?

Vielen Dank und schöne Grüße

Hallo Herr Römermann,
ich konnte das Phänomen nachstellen, bin aktuell etwas ratlos Hier muss ich etwas tiefer in die Analyse eintauchen.

Sie können das Problem aber umgehen indem Sie den UPDATE Befehlt in der MySQL Stored Procedure vor dem SELECT einfügen.

Sobald ich weitere Infos dazu habe gebe ich Ihnen Bescheid.

Hallo Herr Stark,
leider funktioniert das Tabellen-UPDATE auch nicht, wenn ich es vor dem SELECT ausführe.

Es gibt aber im Zusammenhang mit der FlowHeater-Ausführung der Procedure noch ein weiteres Phänomen,
das mir zufällig aufgefallen ist und evtl. Hinweise auf das dahinter liegende Problem gibt.
Wenn ich die Procedure im FlowHeater ausführe und nach der Ausführung versuche, einen beliebigen Eintrag
in der Status-Tabelle zu ändern, dann bleibt die Tabelle solange blockiert, bis ich die Procedure noch einmal im
FlowHeater ausführe oder den FlowHeater beende. Seltsamerweise besteht der Table-Lock dann nur bei der 
Statustabelle und nicht bei der Datentabelle.

Vielen Dank für Ihre Mühen

Dirk Römermann

Hallo Herr Stark,

ich habe nun für mich eine Lösung des Problems gefunden :

Wenn ich nach der letzten UPDATE-Zeile ein "COMMIT;" in der Stored Procedures absetze, wird alles wie gewünscht ausgeführt.
Dies sollte meiner Meinung nach im Normalfall nicht notwendig sein.
Es bleibt wohl ein Table-Lock bestehen, der erst nach Beendigung des Datenbankprozezesses aufgelöst wird.

Es scheint also, als ob bei der Ausführung durch den FlowHeater ein abschließendes COMMIT nicht ausgeführt wird.
Inwieweit dies Ihrerseits beabsichtigt ist, kann ich natürlich nicht sagen.

Vielen Dank im Voraus für Ihr Feedback.

Schöne Grüße
Dirk Römermann
 

Hallo Herr Römermann,

da haben Sie vollkommen Recht, das mit dem COMMIT sollte eigentlich nicht sein. Bei meinen Tests hat es mit dem verschieben des UPDATE Statements vor dem SELECT funktioniert. Ich habe für den Test MySQL Server in Version 8.0.29 verwendet.

Ich kann aktuell nicht sagen woran das liegt, bin weiter an der Analyse dran. Meine Vermutung geht in Richtung AutoCommit Einstellungen. Der FlowHeater macht im Normalfall auf der READ Seite keine explizite Datenbanktransaktion auf, dies geschieht erst wenn ein SQL Statement z.B. über den SQL Heater ausgeführt wird.  Auch mit einem expliziten COMMIT der Transaktion über den FlowHeater wird bei meinen Tests der UPDATE nicht geschrieben  Ich an der Analyse dran ...

Hier mal eine Gute Nachricht. Das Problem mit dem Table Lock wurde in der aktuellen Beta Version behoben.

Download Beta Version
 

Hallo Herr Stark,

wir verwenden hier noch die Version 8.0.25. Ich habe die etwas komplexeren Proceduren mit eingefügtem COMMIT in der Produktivumgebung getestet,
und es funktioniert damit alles soweit.
Ich lasse es jetzt als Workaround dann erst einmal so laufen und freue mich, wenn irgendwann die Fragestellung gelöst ist.
Das abschließende UPDATE steht ja bewusst am Ende der Procedure, da das Exception-Handling bei MySQL nicht besonders komfortabel ist, so dass,
falls die Abfrage aus irgendeinem Grunde abbricht, kein UPDATE der Statustabelle stattfindet.

Vielen Dank für Ihre Bemühungen und geben Sie mir gerne Bescheid, wenn die Fragestellung behoben ist.

Schöne Grüße
Dirk Römermann

Hallo Herr Römermann,

in der aktuellen Beta Version wurde das Problem behoben. Wie ich schon vermutet habe lag das an der AutoCommit Einstellung. Mit dieser Version wird nun immer eine explizite Transaktion inkl. COMMIT bzw. ROLLBACK, auch auf der READ Seite verwendet. Das Verhalten kann über die Eigenschaften beeinflusst werden.

Download Beta Version

Hallo Herr Stark,
vielen Dank für den hervorrangenden Support.
Ich komme dann erst einmal klar.

Schöne Grüße
Dirk Römermann