puh :eek:, die Zeiten hast du noch nicht genannt und seit dem Archivumbau habe ich mehrfach, in den letzten zwei Tagen mindesten fünf mal reaggregiert :rolleyes:.
Update:
Das sind alles LCN Binäreingänge.
27.10. ab 22:xx lief die Reaggregation, da mir auf dem Tablet aufgefallen war, dass die Diagramme nicht angezeigt werden.
Das würde tatsächlich in den entsprechenden Zeitraum fallen… Du kannst ja vielleicht die nächsten Tage mal schauen, ob die problematischen Fälle auf eine Reaggregation fallen. Und ich schaue mal, was da passieren könnte…
Ich schaue die Daten mal genauer an, technisch ist der Status mit mehrfach on in einer Sekunde eigentlich unmöglich, da die von mir genutzte BMI Konfiguration eigentlich mindesten 8 Sekunden on ist.
Kann es sein, dass der Zustand das Ergebnis der Abstürze ist?
Ich hatte ja mindestens 3-4 Reaggregationen, die nicht durchgelaufen sind.
Hallo,
auch bei meinen 2 Symcons:
[ol]
[li]Das Variablen-Logging ist teilweise weg. Manche werden noch geloggt, andere (die früher geloggt wurden) sind aus dem Logging raus geflogen.
[/li][li]Auf einmal sind zig Media-Files in der Symcon Root Struktur. Siehe Screenshot.
[/li][li]
[/li][/ol]
Hilfreich wäre es, wenn man wenigstens mehrere Variablen auswählen und dann das Logging wieder einschalten könnte.
@juergen852: Welche Version hattest du vorher installiert? Hast du davon noch ein Backup, sodass wir das fehlverhalten nachstellen könnten?
Bei den Medien ist dies gewollt und du kannst diese einfach in einen beliebigen Ordner wegsortieren.
paresy
Ich muss nachschauen, was ich an Backups noch finde… Melde mich.
Hi,
ich musste einen Sensor mit Temperatur, Luftfeuchtigkeit und Luftdruck austauschen. Um Daten nicht zu verlieren habe ich im Archive Daten transferieren benutzt und auf die jeweiligen, neuen Variablen gezeigt.
Wunsch wäre das dann auch gleich „Alle Variablenänderungen aufzeichnen“ für die neue Variable aktiviert wird.
Ich hatte es erst aktiviert dann meckerte aber Archive Control beim transferieren weil es ja schon Daten gab. Nach dem Transferieren hatte ich dann aber die Aufzeichnung nicht aktiviert.
Ralf
Die Variable sollte beim Transferieren eigentlich mit allen Archiveinstellungen übernommen werden. Sprich, wird die alte Variable geloggt, dann wird danach die neue auch geloggt. Das ist meiner Meinung nach auch sinnvoll. So werden nämlich beispielsweise auch korrekt Zähler bzw. Standardaggregation gesetzt.
Weißt du, ob das Logging bei der alten Variablen vor dem Transfer aktiv war?
Moin,
die alte Variable gab es nicht mehr. Grund war eine defekte Instanz und ich musste die defekte Instanz mit den Variablen löschen bevor ich eine neue Instanz mit den Variablen anlegen konnte.
Ralf
Auch wenn die Variable nicht mehr existierte, sollten die Archiveinstellungen im Archiv noch vorhanden sein. Das teste ich aber nochmal.
Danke. Ich hoffe aber das es nicht allzu oft bei mir vorkommt.
Ralf
Moin Dr.Niels,
bei Skripten wo mit AC_AddLoggedValues historische Werte zugefügt werden kommt es immer wieder zu dieser Fehlermeldung
07.04.2021, 16:52:00 | Archive Control | Could not delete file 2020/03/11304.csv on 1. try, will retry: boost::filesystem::remove: Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird: „C:\ProgramData\Symcon\db/2020/03/11304.csv“
Dies ist bei Corona-, Zähler- und auch den Sportdaten jeweils der Fall gewesen. Wie kann man das vermeiden oder kann man es ignorieren?
Ergänzend kommt noch hinzu, dass in seltenen Fällen sich die Reaggregation in der Pro Konsole aufhängt - gerade nach solchen Meldungen. Klickt man auf abbrechen hängt das System und kann nur noch mit dem Taskmanager beendet werden.
IP-Symcon 5.5, Windows x64, 17.03.2021, e149a62e5f6a
Gruß
Hans
Moin,
noch ein Nachtrag: das Problem tritt überwiegend bei dem deutlich langsameren Produktivsystem auf. Der sehr viel schnellere Entwicklungsrechner hat das Problem nur bei sehr großen Datenmengen.
Gruß
Hans
Hallo Hans,
schlägt der Zugriff auch immer nur beim ersten Versuch zu (also mit Text „on 1. try“), oder auch weitere und bricht eventuell gar ab?
Es kann gut sein, dass die Datei gerade von einem anderen Prozess genutzt wird, beispielsweise von einem Virenscanner oder dergleichen. Dann kann sie aber halt nicht gelöscht werden und das wird kurz darauf noch einmal probiert.
Moin Dr.Niels,
es gibt manchmal auch mehrere Versuche. Außer den MS eigenen Virenscanner habe ich keine externe Software dafür am Laufen.
Das Problem tritt und trat immer dann auf, wenn Wert mit AC_AddLoggedValues angelegt werden.
Gruß
Hans
Der Fehler ist ja nicht das erste mal aufgetreten. Vorher schlug das Hinzufügen der Werte nur fehl, jetzt wird es mehrfach versucht, was in deinem Fall das Problem auch löst. Ich hatte bei mir recht umfangreich versucht den Fehler (Symcon-intern) nachzustellen, was allerdings nicht geklappt hat. Wenn du also in die Tiefe gehen möchtest, dann müsstest du hier weiter suchen und herausfinden, welcher Prozess für den Zugriff verantwortlich ist.
Moin Niels,
ich werde das weiter beobachten und am Wochenende Tests mit und ohne Defender durchführen. Mal sehen, ob ich neue Erkenntnisse gewinne 
Vielleicht hat der PC ja einen Virus, weil es sich um Corona Daten handelt 
Gruß
Hans
Moin Niels,
dieses kleine Skript
AC_DeleteVariableData(KID_ARCHIV, $IdVar, 0, 0);
AC_SetLoggingStatus(KID_ARCHIV, $IdVar, true);
AC_SetAggregationType(KID_ARCHIV, $IdVar, 1);
AC_AddLoggedValues(KID_ARCHIV, $IdVar, [['TimeStamp' => mktime(0, 0, 0, 1, 1, 2020), 'Value' => 0]]);
AC_ReAggregateVariable(KID_ARCHIV, $IdVar);
liefert
09.04.2021, 16:47:31 | Archive Control | Reaggregation für VariablenID #37262 abgeschlossen! (1 Einträge)
dieses Ergebnis in der Konsole. Öffnet man das Archiv wird auch nur 1 Datensatz angezeigt, was aber falsch ist, denn im Archiv befinden sich 2 Datensätze: Der im Skript angelegte Nullsatz und der seit V5.5 generierte neue Datensatz mit dem Wert Null. Reaggregiert man nun in der Konsole die Variablen so wird danach auch prompt angezeigt, dass 2 Datensätze vorhanden sind
Also ist das Ergebnis der Reaggregation im Skript nicht identisch mit dem aus der Konsole. Auch ein Einfügen von IPS_ApplyChanges(KID_ARCHIV) nach AC_SetAggregationType bringt kein anderes Ergebnis.
Übrigens bringt auch ein weiterer Befehl zum Reaggregieren nach 2 s Pause keine Änderung. Irgendwie wird die vom System angelegte Variable im Skript nicht berücksichtigt.
Gruß
Hans
Moin Niels,
das habe ich getan Die Sequenz im vorherigen Beitrag könnte der Schlüssel zum Problem sein. Du kannst Variablen hinzufügen wie du willst, mit Pausen und ohne Pausen, es wird immer ein Wert weniger angezeigt als real Werte im Archiv vorhanden sind - vermutlich der neue systeminterne Nullsatz.
Die Deadlocks treten nämlich unmittelbar nach Ausführung dieser Sequenzen auf. Meine Vermutung ist, dass dieser nicht angezeigte Nullsatz das Problem auslöst, indem er für das Locken der Datei verantwortlich ist 
Diese Deadlocks habe ich in 3 verschiedenen Skripten in denen historische Daten übernommen werden. Die Sportdaten, Zählerdaten eines Stromzählers und jetzt die Coronadaten. Das kann also eigentlich kein Zufall sein.
Unklar dabei ist, warum es nicht immer passiert und wenn es passiert, warum es dann nicht immer die identische Variable betrifft. Vielleicht hilft es euch ja beim Nachstellen des Fehlers. Da bei mir der Fehler auf dem langsameren System häufiger auftritt könnte es sinnvoll sein, dass die Tests nicht unbedingt auf einem 12 Kerner durchgeführt werden
Nachtrag: Wenn man das Archiv öffnet und nur die eine Variable reaggregiert, wird anschließend nur ein Datensatz angezeigt - also gleiches Verhalten wir im Skript. Reaggregiert man allerdings alle Variablen dann werden 2 Datensätze angezeigt 
Gruß
Hans
Der „fehlende Wert“ kommt daher, dass das Archiv die geloggten Werte alle Minute schreibt, AC_AddLoggedValues ist hiervon eine Ausnahme, die sofort geschrieben wird. Daher ist bei einer direkten Ausführung der Reaggregation dann auch nur der hinzugefügte Wert da. Wenn du ein wenig wartest und dann reaggregierst, dann werden auch beide Werte da sein. (Und wenn du es nicht tust, dann wird der zusätzliche Wert nach spätestens einer Minute kontinuierlich dazu aggregiert)
Das ist also in dem Sinne kein Fehler sondern der Struktur des Archivs geschuldet.
Wo kommen jetzt eigentlich die Deadlocks her? Bisher hattest du die (hauptsächlich kosmetische) Meldung, dass das Schreiben mehrfach erfolgt und halt der eine Datensatz, der erst später dazukommt. Deadlocks habe ich gerade nicht parat. Verstehe ich da etwas falsch?