Inoffizielles deutsches Xbase-Forum

Hallo Jimmy

je nach dem wo der User das Programm stehen lassen hat kann man davon ausgehen, dass ein programmierter Eingriff in den Ablauf eines Programm z.B. durch "Admin"-TimeOut zwangsweise zu unklaren Datenbeständen führen muss.

Einfaches Beispiel:
Der User legt in einer Warenwirtschaft eine neue Rechnung an und lässt das Programm z.B. im Eingabefeld "Preis" stehen. Wie soll das Programm nun bei einem "Admin"-Timeout witer verfahren?
Den Feldwert beibehalten oder löschen? Den gesamten Eintrag anlegen oder löschen?
Alles rückgängig machen oder oder oder.
Und was macht das Programm mit möglichen Validierungsfehlern?

Ich hatte früher so etwas eingebaut um nachts die User rauszuwerfen. Hatte einige Varianten ausprobiert und schlussendlich nichts entsprechendes mehr in aktiven Systemen.

Meine Lösung:
Durch organisatorische Maßnahmen ist es sehr selten geworden, dass nachts noch ein PC läuft bzw. die Warenwirtschaft.

Ob an einen User nach einer bestimmten Zeit inaktiv rauswirt oder nicht iost IMHO Geschmakssache, ich tue es normal nicht. Zu einem Inkonsisten Datenstand darf es dadurch aber nie kommen. Dafür muss das Programm sorgen. Wenn man mit SQL arbeitet kann man dies immer zur Gänze verhindern (Transaktionen). Alles andere ist sch*.

Hi

das Problem ist noch immer vorhanden, nach einiger Pause ist es mit der selben EXE Version in den vergangenen Tagen wieder gehäuft aufgetreten.
Einen HInweis bekamm ich noch: Der Fehler erscheint beim VERLASSEN der Maske, einer do while Schlaufe mit ESC
Die betroffene Zeile ist aber einiges VOR der do while schlaufe ...

Dies nur bei einem Kunden bei den anderen ist das Problem (noch) nicht wieder aufgetreten.

Gruss Carlo

Hallo

was kann dazuführen dass beim EXIT aus einer do while Schlaufe eine Fehlermeldung angezeigt wird die auf eine Zeile VOR dieser Schlaufe verweisst?

Gruss Carlo

eventuell endloser Rekursiv-Aufruf einer Funktion mit dieser Schleife...?

Hallo Roland

das kann ich eigentlich ausschliessen.
In der Schleife ist eine Navigation mit der die Postitionen einer Rechnung im unteren Teil des BS angezeigt und gescrollt werden können. Beim Verlassen mit ESC = EXIT kommt die Fehlermeldung mit bezug auf eine Zeile am Anfang der Funktion im oberen Teil de BS einmalig Rechnungsdaten anzeigt. Wird zu Testzwecken die DBFNTX verwendet kann der Fehler nicht ausgelöst werden. Unter der ADSDBE gelingt es in bestimmten Netzwerken relativ schnell. Ein Verzicht auf ADS ist momentan nicht angedacht.

Gruss Carlo

ramses hat geschrieben: ↑Do, 17. Aug 2017 12:18 ...
a := field->skontoabz/(field->skontober/100)
b := Str( a , 10 , 1 ) ---->>> BUMM

Wenn ich es richtig verstanden habe, existiert der Fehler weiterhin.
Hilft ?

Auch mit Round() das selbe. Ich bin aber auf einer Spur was es sein könnte.....

Probier doch mal F2Bin. Wenn es klappt, analysiere das Ergebnis oder gleich mit Bin2F wieder zurückwandeln.
Michael

Michael
ich vermute momentan dass die EXE im speicher korrupt wird. Bin am suchen...
Gruss Carlo

ramses hat geschrieben: ↑So, 15. Okt 2017 20:57 ich vermute momentan dass die EXE im speicher korrupt wird. Bin am suchen...

hm ... aber du sagtest doch

Wird zu Testzwecken die DBFNTX verwendet kann der Fehler nicht ausgelöst werden

also ist es ein DBE Problem
DBFNTX kann man kaum falsch konfigurieren aber ADS ...

Jimmy
dass der Fehler einer Zeile VOR einer do while Schlaufe beim EXIT aus der Schleife angezeigt wird, die Zeile vor der Schlaufe korrekt abgearbeitet wird zeigt mir dass etwas im Ablauf nicht stimmen kann. Da es ab und zu geht bringt mich auf eine korrupt gewordene EXE .....
Gruss Carlo

ramses hat geschrieben: ↑Fr, 13. Okt 2017 17:26 Auch mit Round() das selbe. Ich bin aber auf einer Spur was es sein könnte.....

Passiert der Fehler wirklich bereits beim Berechnen von a, also bei Round?

Hallo UliT

ich bekomme den Fehler beim verlassen einer Schlaufe, die Zeile auf welche die Fehlermeldung hinweist liegt VOR der Schlaufe und wurde vor der Schlaufe korrekt abgearbeitet. Das Programm dürfte diese Zeile eigentlich gar nicht mehr erreichen. Ich vermute daher dass irgendetwas die EXE im Speicher oder den Stack überschreibt verändert oder sonst wie korrupt macht.

Der Fehler tritt auf wenn die Schlaufe mit ESC --> EXIT verlassen wird. Bis zum drücken von ESC läuft alles korrekt.

Gruss Carlo

Stell doch mal bitte die Schlaufe hier ein.

Hallo UliT

ich konnte das Problem vermutlich lösen.
Scheinbar ist die Ursache die mit UPX gepackte EXE Datei. Seit auf dem System eine ungepackte EXE eingesetzt wird ist der Fehler NICHT erneut aufgetreten und kann nicht mehr provoziert werden.
Auch der Speicher und Resourcenverbrauch des ungepackten Programms ist deutlich geringer. Die Anwender berichten auch dass das Programm deutlich flotter läuft.

Gruss Carlo

ramses hat geschrieben: ↑Di, 31. Okt 2017 18:01Scheinbar ist die Ursache die mit UPX gepackte EXE Datei.

3 Seiten Thread und erst jetzt kommst du mit einer "wichtigen" Information ...

Jimmy

ich habe UPX zum packen seit 2008 verwendet. Das packen hatte ich im Build-Prozess. Obwohl ich öfters nicht Funktionierende UPX gepackte EXE's hatte sind diese immer beim Start gecrasht und konnten durch Codeanpassungen jeweils beseitigt werden.

Dass das UPX packen zu derart perfiden Problemen führen kann konnte ich mir beim besten Willen nicht vorstellen. Auf diese Ursache kam ich erst per Zufall durch Bargespäche über "Misterien" mit einem IT-Professor nach einem Workshop in San Diego.....

Bitte entschuldige, hätte ich diese Ursache auch nur im kleinsten auch nur vermutet hätte ich diesen Versuch als Lösung als erstes getestet, den Thread nicht geöffnet und zudem viel, viel, sehr viel Zeit, Geld und Aerger gespart!!!!!!
Denkst du wirklich ich hätte dieses Detail absichtlich nicht erwähnt??!!?????



Gruss Carlo

Danke für die interessante und wichtige Information!