Bug im Dashboard

Hallo alle zusammen,

@Steiner

Ich habe folgendes Problem beim Dashboard:

Wenn ich ein Memo einfüge und dann „Speichern und hochladen“ betätige
schmiert IPS ab. Wenn ich dann IPS beenden will kommen zwei Meldungen.

siehe Bilder.

Haben Sie eine Ahnung was das ist?

Bis dann

Schablone

Fehler_1.jpg

Fehler_2.jpg

Kann das Problem bei mir nicht nachstellen.
Wir sind hier im Forum übrigens alle per Du.:wink:

Hallo Ferengi-Master,

ich kann selber nicht ganz nachvollziehen was da passiert.
Gestern hat’s mir die komplette Applikation zerissen.

Zum Glück hatte ich mit der Integration des „SQLite DUG Tool“ die Applikation
gesichert, so dass nur ein paar Tage futsch sind.

Ich bin gerade an dem Punkt eine Instanz des Mediaplayers zu integrieren.
Um die aktuell geladene „Tracklist“ anzuzeigen wollte ich ein Memo benutzen.
Gestern Abend war dann alles futsch.:frowning:

Als ich heute an derselben Stelle angekommen bin (wenn man alles schon mal gemacht hat gehts schneller ;)) habe ich gemerkt das beim
einsetzen eines leeren Memos schon IPS die Grätsche macht.

Zum Glück bin ich Kummer durch WinCC gewohnt.

Besten Dank für deine Anmerkung.

Nach dem Mediaplayer steht deine Terminverwaltung auf dem Programm.
Freu mich schon drauf. Werde aber vorher die Applikation sichern.
Du weißt ja, " Der Esel stößt sich die Hufe immer nur einmal an den selben Stein" oder so :o

Bis dann

Martin ähhhh Schablone

Na dann noch viel Erfolg!:slight_smile:

Das selbe Problem hatte ich neulich auch mal wieder. Schade, ich dachte, das wäre mittlerweile behoben. Es tritt nämlich schon seit ziemlich langer Zeit immer mal wieder auf, wenn man „speichern und hochladen“ wählt.

Fürs nächste Mal: Wenn diese Meldung kommt, ist noch nichts verloren. Du solltest aber die Konsole sofort beenden und neu starten. Dabei wirst du fieserweise gefragt, ob du noch mal speichern willst. Auf keinen Fall machen, denn sonst sind die Daten tatsächlich auch serverseitig futsch. Einfach die Instanz abschießen und neu starten.

Falls es hilft, bei mir tritt das nur auf wenn ich von einem anderen Rechner aus die Konsole benutze. Bei den Entwicklern offenbar gar nicht, denn gemeldet wurde das Problem wie gesagt schon vor langer Zeit. Vmtl. ließ es sich einfach nicht nachstellen.

Wenn es einem das mühselig zusammengefrickelte Dashboard zerlötet, ist das sehr ärgerlich.
:confused::eek::frowning:

Wenn man es aber weiß, dann ist es, nun ja, bloß noch ein bisschen anstrengend.
:loveips:

Hatte das erst vor zwei Tagen wieder (arbeite lokal).

Beim speichern wird offenbar die *.bin Datei nicht komplett geschrieben.
Ich habe diese mit einem Texteditor geöffnet und konnte darin noch ein paar meiner Änderungen finden.
Allerdings fehlt der Datei am Schluß ein Stück, welches ich dann aus einer Vortagessicherung wieder reinkopiert habe.
Ein Teil meiner Änderung war dann aber leider weg.

@paresy
Währe es möglich beim Speichern zuerst die orginal *.bin als *.bak zu sichern, dann ist zumindest der letzte funktionsfähige Stand noch vorhanden.

m-f-a

Hallo Leidensgenossen,

Ich habe das Problem jetzt kontinuierlich. -> Auch lokal!!
Immer wenn ich sage „Speichern und hochladen“ hängt sich IPS komplett weg.

Genau so mach ich es jetzt auch. Wenn ich IPS neustarte und dann nochmals speichern will kommt immer das gleiche. s.u.

@Steiner

Ist das Problem bekannt?
Wird daran gearbeitet?
Was mache ich in diesem Fall?
Gibt es für mich eine Zwischenlösung bis zum nächsten Update?

Zur Info: Die Meldungen kommen in der Reihenfolge 3, 4, 5, 6

Bitte, Bitte, Hiiiilfe

mfg

Martin

Fehler_3.jpg

Fehler_4.jpg

Fehler_5.jpg

Fehler_6.jpg

Das Problem ist nicht bekannt. Du kannst mir gerne dein Formular schicken und ich sehe, ob das Problem dann hier auftritt.

paresy

Hallo Parsey,

besten Dank für deine Antwort.

Brauchst Du nur die .bin Datei oder den kompletten IPS-Ordner?

mfg

Martin

Du kannst mir gerne dein Formular schicken

also: die BIN-Datei

MST

Hallo Paresy!
Ich habe die selbe Fehlermeldung.

Bei mir passiert das auch öfters.
Die .bin Datei hat beim speichern und hochladen diese Fehlermeldung gebracht.

Danach war sie nur noch 4KB gross und nichts mehr"drin".:mad:

Schönen Gruß
Egon

Das kann ich nicht glauben. Wir haben schon vor längerer Zeit darüber diskutiert. Leider finde ich meinen Beitrag nicht wieder.

Z.B. http://www.ip-symcon.de/forum/f52/dashboarddatei-beim-beenden-fehlermeldung-groesse-nur-noch-0-kb-6987/

Bei mir waren es mehrere Stunden Arbeit und mehrere hundert Elemente, die weg waren.

Das Problem tritt immer mal wieder beim Speichern auf. Inzwischen sichere ich während der Entwicklung sehr häufig.

Hallo Paresy,

hast Du in meinem Formular schon was finden können?

Bis dann

Schablone

Ich kann das Formular ohne Probleme laden und speichern. Habe jetzt bestimmt 20mal gespeichert - ohne irgendwelchen Fehler.

Vielleicht noch einen Tipp welche Umstände diesen Fehler auslösen kann?

paresy

Hallo Paresy,

ich bekomme den Fehler nicht mehr nachgestellt.
Ich habe aber auch meinen PC von Vista auf Windows 7 umgestellt.

Ist halt Vorführeffekt :frowning:
Tu mir leid.

Vieleicht können meine Leidensgenossen noch ein bisschen was erzählen.

Nochmals sorry für die investierte Zeit.

Bis dann

Schablone

Hallo,

@paresy
ich kann auch nicht sagen wann genau das auftritt (eigentlich immer wenn man es nicht brauchen kann;)).
Wenn du aber meinen Vorschlag von weiter oben umsetzen könntest, dann kann man beim nächsten mal die alte *.bin und die defekte an dich zur Fehlersuche senden.

m-f-a

Hallo,

greife das Thema noch mal kurz auf, habe auch dieses Problem „ab und zu“, ich speicher jetzt immer bevor ich „speichern und hochladen“ klicke seperat ab.
Das Problem habe ich schon ca. 1,5 Jahre, es wurde schon mal diskutiert aber es gab keine Behebung. Ich lebe einfach damit, wenn mann viel sichert hat man ja kein Problem, aber die ersten mal taten schon weh…

Mein System:
Win 7, arbeite lokal, habe verschiedene Forms und ich glaube bei allen ist es schon mal vorgekommen.

Das Problem ist definitiv da und es wurde auch früher schon mal besprochen. Hab auch schon einige Stunden dadurch verloren. Als das schon mal diskutiert wurde, sah es so aus als ob das hauptsächlich auftritt wenn man über das Netzwerk arbeitet, was auch auf mich zutraf. Also mein aktuelles Dashboard macht das Problem bei ca. jeden 3ten abspeichern. Ich hab auch den Eindruck, das es häufiger vorkommt wenn das Dashboard komplexer wird.

Gruß
Smudo

tritt schon lange auf und auch jetzt immer wieder, aber leider wieder zu stochastisch, um es gesichert zu replizieren. Häufigkeit nimmt zu mit

  • geringerer Bandbreite (remote per UMTS am häufigsten, aber auch bei langsamem lokalen WLAN vom Client zum Server)
  • größerer Dateilänge / Komplexität
  • höherer Last auf der Leitung (z.B. wenn parallel IP-CAMs im Abruf)

Ursache ist offenbar eine unvollständige Kontrolle der Übertragung aller Dateiblöcke bzw. ein zu früh wirkendes Timeout

Das Gegenstück dazu ist ziemlich stabil wiederholbar (Remote Form öffnen per UMTS-Zugang) zu beobachten: Je langsamer die Leitung, umso häufiger bleibt der Ladebalken einfach irgendwo stehen. Dabei läßt sich sehr gut beobachten, wie z.B. nach "fremdlast"bedingtem Stillstand des Ladevorgang nochmal versucht wird, dann aber nach dem nächsten Stopp endgültig und für alle Zeit hängenbleibt.

Wenn intern das gleiche Verfahren der Übertragung / Timeout usw. für den umgekehrten Weg wirkt, ist klar, warum die Dateien unvollständig übertragen werden.

UNBEDINGT sollte eine Sicherungsstrategie per *.bak-Datei eingebaut werden, dabei aber auch darauf geachtet werden, dass die finale Umbenennung der neuen *.bin- und der dann gültigen *.bak-Datei erst nach VOLLSTÄNDIGER Übertragung erfolgt! Eine einfache Kontrolle z.B. per Anzahl der zu übertragenen Bytes kann sogar einseitig, also ohne aktive Kommunikation mit der „Gegenstelle“ erfolgen, denn dazu wäre doch nur im einfachsten Fall ein Abgleich mit der Dateilänge im Zielsystem notwendig, was der Sender selbst kontrollieren könnte und darauf folgend „dynamisch“ weitere Sendeversuche der fehlenden Blöcke initiieren könnte.

Das nur mal so als Idee. Natürlich wäre ein echtes Handshake hier viel sinnvoller, allein um zu verhindern, dass Reihenfolgen von Datenblöcken durcheinander kommen.

===== Workaround: =====
Ich entwickle mittlerweile nur noch

  • entweder direkt an einem (abgesetzten) Entwickler-Serversystem
  • für Wartung an Produktivsystemen nur noch direkt auf diesen per Remoteconsolen-Sitzung

Das natürlich immer gepaart mit regelmäßigen Sicherungen

Aber, wie gesagt, einfache *.bak-Strategien und Zieldatei erst in finanlen Dateinamen umbenennen (und DANN erst dabei altes File überschreiben) nach 100%igem Abschluß des Schreibvorganges bzw. der Übertragung, das sollte als Verfahren doch nicht so ganz neu sein, oder? Kann mich an sowas schon bei Wordstar in den frühen 90ern erinnern… :rolleyes:

Gruß Gerd

kann ich auch bestätigen, sogar mit nur einem element aufm dashboard