save to bringt Fehler: Versuch nicht persistente Daten...

Alle Fragen um die Programmierung, die sich sonst nicht kategorisieren lassen. Von Makro bis Codeblock, von IF bis ENDIF

Moderator: Moderatoren

Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: save to bringt Fehler: Versuch nicht persistente Daten...

Beitrag von Jan »

DelUser01 hat geschrieben: Fr, 28. Jul 2017 9:10Schlussendlich merkt der Kunde vom Unterschied alt/neu nicht viel und daher ist das Umstellen für mich eine unbezahlte aufwendige Fleißarbeit.
Die aber letztendlich Dir bei der weiteren Wartung des Projekts wieder zu Gute kommt. Sich also insgesamt dann doch wieder lohnt.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: save to bringt Fehler: Versuch nicht persistente Daten...

Beitrag von Tom »

SAVE TO verwendet die Symboltabelle, an die man auch herankommt, über Symbolinfo(). SAVE TO sichert private und globale Variablen, die der angegebenen Namenskonvention entsprechen, so dass man Symbolinfo(MEMVAR_PRIVATE) und Symbolinfo(MEMVAR_PUBLIC) abrufen muss, um zu sehen, was SAVE TO da gerade sichern will, obwohl das nicht geht. Irgendwo gibt es eine Variable, die den Namenskonventionen genügt, aber eben nicht-persistent ist, weshalb sie nicht gesichert werden kann. Sie ist vermutlich in den Rückgaben von Symbolinfo() zu finden. Wenn das nur gelegentlich auftritt, muss man den Code nach der Namenskonvention durchsuchen. Vielleicht ist die Variable auch schon falsch in einer XPF enthalten, die gelegentlich über RESTORE FROM restauriert wird. Oder das Restaurieren erfolgt, wodurch die Variable mindestens privat initialisiert ist, die Variable bekommt dann später ein Objekt zugewiesen und es kracht. So oder so, direkt vor SAVE TO sollte Code eingefügt werden, der die Arrays irgendwo protokolliert, die Symbolinfo() zurückgibt. Dann findet man auch den Tatverdächtigen.

Prinzipiell sind SAVE TO/RESTORE FROM mit großer Vorsicht zu genießen, da es keine Mechanismen gibt, die vor Kollisionen im Netz schützen. Die muss man selbst bauen. Tabellen, INIs, XML-Dateien oder ähnliche Verfahren sind meistens sinnvoller. Aber, ich weiß - das sagt sich leicht. :wink:
Herzlich,
Tom
DelUser01

Re: save to bringt Fehler: Versuch nicht persistente Daten...

Beitrag von DelUser01 »

sicherlich könnte man statt save to zu verwenden Ersatzwege suchen und gehen um das Gewünschte zu erreichen. Wenn es so einen nützlichen, mächtigen Befehl gibt sollte dieser aber auch verwendbar sein.
Eine Abhilfe wäre da schon ein weiterer Parameter mit dem man Problemstellen überspringen könnte. Also wenn in save to eine Variable nicht gesichert werden kann sollte es nicht zum Absturz kommen sondern entsprechend dem Zusatzparameter entschieden werden (z.B. .T. = skip on error / .F.= stop on error). Damit wäre das Ganze schon behoben. Oder Alaska müsste eine Meldung zurückgeben welche die betroffene Variable nennt. Dann käme man auch weiter. Oder eine Art "Prüfaufruf" vor dem eigentliche save to.
Dann müsste man auf den Befehl nicht verzichten.

@Jan
Bin schon längere Jahre sporadisch am Umstellen auf den neuen Weg. Ist aber eben aufwendig und an vielen Stellen notwendig.
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: save to bringt Fehler: Versuch nicht persistente Daten...

Beitrag von Tom »

@Roland: Wie geschrieben - hol Dir die Symbolinfo und schau nach, was da weggesichert werden soll, was Du eigentlich nicht sichern willst. Und Du kannst natürlich auch eine SEQUENCE aus der Angelegenheit machen, also sie eine entsprechende Kontrollstuktur einbetten. Oder den Fehler im Errorsys einfach ignorieren. Das Problem wäre dann aber, dass vermutlich ab der betroffenen Variablen - alphabetisch sortiert - alle anderen in der Sicherung fehlen würden.
Herzlich,
Tom
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: save to bringt Fehler: Versuch nicht persistente Daten...

Beitrag von ramses »

Hallo Roland

ich hatte die Crashes damals mit dem "like m_* weg bekommen. Allerdings habe ich immer konsequente Namensgebung der Variablen verwendet. m_ .... waren solche die früher (Clipper) aus .MEM und unter xbase aus den xpf Dateien kamen aber die Probleme waren nie ganz weg. Erst der Weg wie Tom schreibt brachte endgültige Abhilfe.
Prinzipiell sind SAVE TO/RESTORE FROM mit großer Vorsicht zu genießen, da es keine Mechanismen gibt, die vor Kollisionen im Netz schützen. Die muss man selbst bauen. Tabellen, INIs, XML-Dateien oder ähnliche Verfahren sind meistens sinnvoller. Aber, ich weiß - das sagt sich leicht. :wink:
Gruss Carlo
Valar Morghulis

Gruss Carlo
DelUser01

Re: save to bringt Fehler: Versuch nicht persistente Daten...

Beitrag von DelUser01 »

Hallo

hatte das mit SymbolInfo schon umgesetzt, nur nicht bei diesem Aufruf mit Except.
Habe das jetzt erweitert. Mal sehen was passiert. Mein Fehler (schäm...).
DelUser01

Re: save to bringt Fehler: Versuch nicht persistente Daten...

Beitrag von DelUser01 »

...und immer noch Fehler...

Die Betroffene Private Variable die den Fehler verursacht konnte ich herausfinden.
Ist ein mehrdimensionales Array mit vielen Blöcken.
Ob eine Variable mit SAVE TO gespeichert werden kann prüfe ich mit

Code: Alles auswählen

aTmp := SymbolInfo( MEMVAR_PRIVATE )

FOR nCnt1 := 1 to Len( aTmp )

   lError    := .F.
   bErrBlock := ErrorBlock( { | o | Break( o ) } )

   BEGIN SEQUENCE
      cSymbol := aTmp[nCnt1,1]
      cSymMem := "MEMVAR->" + cSymbol
      uValue  := Var2Bin( cSymMem )
   RECOVER
      lError := .T.
   ENDSEQUENCE

   ErrorBlock( bErrBlock )

*   If lError

      AAdd( aLocal , { cSymbol , aTmp[nCnt1,2] } )
      &( cSymMem ) := NIL

   ENDIF

NEXT nCnt1
Ich kann heute nicht mehr sagen warum ich die Variablen mit VAR2BIN prüfe. Die betroffene Variable scheint auch die einzige zu sein die bei SAVE TO Fehler verursacht.

Wie kann man sonst noch prüfen ob die MEMVAR mit SAVE TO gespeichert werden kann??
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: save to bringt Fehler: Versuch nicht persistente Daten...

Beitrag von AUGE_OHR »

ich lese das SymbolInfo() eine 3th Spalte mit MEMVAR_PRIVATE hat :
In der dritten Spalte befinden sich logische Werte.

Der Wert .T. (wahr) bedeutet, daß die entsprechende PRIVATE Variable zur Zeit der Ausführung von SymbolInfo() sichtbar ist.
Im Fall von .F. (falsch) ist die Variable durch eine andere PRIVATE Variable gleichen Namens "überdeckt" und nicht sichtbar.
wenn Alaska das extra in die Hilfe schreibt muss das was bedeuten ...

Tom hatte ja schon mal das Problem mit "doppelten" Namen angesprochen.
wenn man eine PRIVATE ein weiteres Mal definiert ... was passiert dann ?
DelUser01 hat geschrieben: So, 30. Jul 2017 1:19

Code: Alles auswählen

      cSymMem := "MEMVAR->" + cSymbol
      uValue  := Var2Bin( cSymMem )
Ich kann heute nicht mehr sagen warum ich die Variablen mit VAR2BIN prüfe.
da du die nicht weiter auswertest oder ins Array aufnimmst sind die wohl nur aus Debug Zwecken vorhanden.
ich kennzeichne solche Stellen mit
#IFDEF DEBUG
...
#ENDIF
womit der Code dann auch nur in der DEBUG Version verwendet wird
gruss by OHR
Jimmy
DelUser01

Re: save to bringt Fehler: Versuch nicht persistente Daten...

Beitrag von DelUser01 »

Hallo Jimmy

Die Zeile

Code: Alles auswählen

uValue  := Var2Bin( cSymMem )
hat nur die Funktion zu testen, ob es zu einer Fehlermeldung Kommt. Ist das der Fall, dann schreibe ich NIL in die Variable, damit es bei SAVE TO nicht zum Fehler kommt.
Hat wohl in der Vergangenheit funktioniert, jetzt scheinbar nicht mehr. Der Inhalt der betroffenen Variablen (mehrdimensionales Array mit Blöcken) wird in dieser Form schon seit ca.10 Jahren verwendet. Auch die Blöcke darin sind seit längerer Zeit unverändert.

Bei den Abstürzen der vergangenen Wochen scheint es auch immer nur um die gleiche Programmstelle und vermutlich auch die beschriebene Variable zu gehen.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: save to bringt Fehler: Versuch nicht persistente Daten...

Beitrag von AUGE_OHR »

hi,

der Error Block ist doch nur weil du ein Problem hast.
das Problem "könnte" sein das PRIVAT "doppelt" sind.

so wie ich das richtig verstehe "sollte" man das mit dem Parameter aus der 3th Spalte "prüfen" können-
gruss by OHR
Jimmy
DelUser01

Re: save to bringt Fehler: Versuch nicht persistente Daten...

Beitrag von DelUser01 »

Hallo Jimmy
AUGE_OHR hat geschrieben: So, 30. Jul 2017 18:26das Problem "könnte" sein das PRIVAT "doppelt" sind.
Habe ich überprüft, die betroffene Variable wird nur in dem PRogrammabschnitt Privat angelegt und verwendet.
Antworten