Negative Werte dürften da gar nicht drinnen sein.
Ich nehme an, das der Fehler mit dem Umbau des Archives zusammenhängt.
Mein eigentliches Programm was diese Systematik nutzt läuft schon seit Jahren.
In der Datei habe ich dann mal nach einem Datum gesucht und fand es 1472 mal in der gleichen Datei!
Anscheinend werden neue Daten nicht nur angahängt sondern das ganze momentane Archiv verdoppelt sich.
Den ersten Fehler kann ich nachstellen. Danke für das Skript! Das hat die Arbeit ordentlich erleichtert! Ich bin dran und schaue mal, was da passiert. Beim Verdoppeln der Datei war ich noch nicht dran. Ich kann mir aber nicht vorstellen, dass das so in jedem Falle passiert. Wenn der Fehler im Archiv liegt, dann wird das wohl eine unglückliche Konstellation bei dir sein, die es zu finden gilt. Ich probiere es aber erst einmal nochmal selbst.
Ich denke das kann an dem Befehl „AC_AddLoggedValues“ liegen,
den verwenden bestimmt nicht viele!
Wenn du noch irgendwelche Daten von mir brauchst, sag bescheid.
Ich kann dir auch gerne so eine Verdoppelungsdatei schicken!
Die Unterstrich-Dateien sind spannend. Diese werden tatsächlich von AddLoggedValues angelegt. Um Datenverlust zu verhindern während die neuen Werte eingetragen werden, werden die neuen Werte gemeinsam mit den alten in der Unterstrich-Datei gespeichert. Wenn das erfolgreich abgeschlossen ist, wird die alte Datei ohne Unterstrich gelöscht und die Unterstrich-Datei umbenannt (also ohne Unterstrich). Die Dateien sollten also nicht bei dir bleiben. Sollten die Dateien beim nächsten Aufruf tatsächlich noch da sein, dann würde das die Verdopplung aber erklären. Da kann ich sicherlich nochmal ein paar Checks einbauen. Hast du irgendwelche Fehler im Log?
Warning: boost::filesystem::remove: Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird: „C:\ProgramData\Symcon\db/2021/02/16689.csv“ in C:\ProgramData\Symcon\scripts\10114.ips.php on line 461
Nach dem Schreiben der Werte mit AC_AddLoggedValues führe ich natü+rlich noch folgenden Befehl aus!
Von der zeitlichen Abfolge her sieht es im Log so aus, das die Fehlermeldung genau mit dem Reaggregieren der aktuellen Datei zusammenfällt!
01.03.2021 00:20:06 | 52542 | MESSAGE | Archive Control | Reaggregation für VariablenID #16689 wird durchgeführt... 01/2021! (4461 Einträge)
01.03.2021 00:20:07 | 00000 | CUSTOM | Enercon | Verfügbarkeit ermittelt
01.03.2021 00:20:07 | 10114 | WARNING | ScriptEngine | Result for Event 10116
Nummer: 0
...
...
...
<b>Warning</b>: boost::filesystem::remove: Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird: "C:\ProgramData\Symcon\db/2021/02/16689.csv" in <b>C:\ProgramData\Symcon\scripts\10114.ips.php</b> on line <b>461</b><br />
Die letzte Meldung vom Archiv beziegt sich auf die Datei 01/2021 und der Fehler entsteht bei der Datei 02/2021, könnte also zusammenfallen!
So, zum Logging der negativen Zahl habe ich jetzt nochmal tiefer geschaut. Das Skript stolpert hier darüber, dass beim Setzen der Variablen eine Nachricht abgesetzt wird (VM_UPDATE), auf die das Archiv lauscht und dann, falls die Variable geloggt wird, den Wert abspeichert. Diese Nachricht ist allerdings kurz „unterwegs“ und kommt dann erst nach dem Aufruf von AC_SetLoggingStatus (52542, $ID,True); an. Dann ist nun wieder das Logging aktiviert. Für dein Skript kannst du das beheben, indem du vor diesem Aufruf ein kurzes Sleep (vielleicht 500ms?) einbaust und so darauf wartest, dass die Variable gesetzt wird und erst danach das Logging wieder aktiviert wird.
Früher war das Archiv beim Übernehmen „langsamer“ wodurch das Sleep indirekt gegeben war. Seit der 5.5 haben wir dort sehr viel optimiert und dadurch ist das schon immer dagewesene Problem jetzt erst sichtbar geworden (Besonders fies - ich weiß).
Leider können wir an diesem Problem nicht wirklich etwas ändern, da wir diese Asynchronität nicht ausbauen können. Magst du es mit dem Sleep einmal testen?
Das mit dem Sleep geht!
Ich als Anwender kann mir aber doch nicht bei jedem Befehl gedanken machen, wie das Timing im Hintergrunde ist. Dazu fehlen mir ja die Infos?
Schreibt Ihr das bei diesem Befehl bitte in die Doku!?
Den Fehler mit dem Zugriffsfehler kann ich bei mir übrigens nicht nachstellen. Kannst du mir vielleicht ein Backup von dir schicken? Dann versuche ich es nochmal damit. Ich vermute allerdings, dass hier irgendwelche Zugriffsprobleme seitens des Betriebssystems vorliegen. Ich habe den Code der beiden Funktionen noch einmal durchgeschaut und eigentlich sollte es nicht möglich sein, dass die sich „überschneiden“. Aber vielleicht habe ich ja etwas übersehen, daher würde ich es gerne nochmal mit deinem Backup ausprobieren.
@Dr.Niels
In der betreffenden Logdatei finde ich 21 Treffer bezüglich der Fehlermeldung!
Warum verschwindet die _Datei eigentlich nicht bei dem nächsten Zugriff?
Ich hab mal probiert so ne Datei zu löschen!
Dazu brauche ich Admin-Rechte?
Ist das so richtig?
Niels, vielleicht erinnerst du dich an das Testprogramm was ich dir vor einiger Zeit gemailt hatte, wo es genau um diesen von Schuggi genannten Fehler ging. Ich kann jederzeit dieses Skript dann nochmals bei mir starten, wenn du Änderungen vorgenommen hast.