Inoffizielles deutsches Xbase-Forum

Hallo

in letzter Zeit häufen sich in meinen Programmen Fehlermeldung in der Funktion str() alle betroffenen Zeilen haben die letzten 10-20 Jahre OHNE solche Fehlermeldungen gearbeitet.
Der Funktion wird jeweils das Ergebnis einer Rechnung z.B. aus 2 Datenbankfelder übergeben:
Die Fehlermeldung:

------------------------------------------------------------------------------
oError:args :
-> VALTYPE:N
VALUE: 0.00
-> VALTYPE:N
VALUE: 10
-> VALTYPE:N
VALUE: 1
canDefault : F
canRetry : F
canSubstitute: T
cargo :
description : Ungültiger numerischer Wert für Operation
filename :
genCode : 12
operation : str
osCode : 0
severity : 2
subCode : 5
subSystem : BASE
thread : 1
tries : 0

Beide Datenbankfelder sind vom Typ "N" Nummerisch Länge 10 Stellen, 2 Dez. Stellen. Ein oder beide Werte können 0 enthalten.
Division durch 0 ist im Errorhandler abgefangen so dass jeweils 0 Zurückgegeben wird.
Der Zugriff auf die Datenbank erfolgt über ADSDBE.
Xbase-Version 2.0.807
ADS-Version 10.10.0.49 axcws32.dll Version 10.10.0.49

Es ist nicht nur obige Zeile betroffen, sondern viele verschiedene Zeilen mit jeweils unterschiedlichen Auswertungen(Rechnungen).
Der Fehler kann nicht bewusst herbeigeführt werden.
Er schlägt sporadisch zu, Tagelang gar nicht, dann wieder mehrfach.
Obige Zeile ist seit über 20 Jahren im Code, die vergangenen Jahre hat es auch nicht ein Problem gegeben, erst seit einer der letzten Xbase Versionen häufen sich diese Fehler auf eine Anzahl die der Kunden nicht mehr aktzeptiert.

Kennt jemand diese neue Erscheinung?

Gruss Carlo

Hallo Carlo,

die Fehlermeldung sagt ja ganz eindeutig, das Du da drei numerische Werte an Str() übergeben hast. DAS kann also jedenfalls nicht der Fehler sein.

genCode 12 sagt: The variable is too long to fit into field. -- Invalid numeric value (e.g. 3 % 0 or float number is too large for array index)

Wobei sich mir die Frage stellt: Warum ist 0.0 zu groß, um als 10.1 dargestellt zu werden?

Ansonsten: Alaska fragen. Sowas können vermutlich nur die wirklich beantworten.

Jan

Hallo Jan

Danke für deine Bestätigung. Weisst du langsam beginne ich doch zu zweifeln, jedenfalls komme ich mir gegenüber dem Kunden blöd vor ... wie erklährts du dass Programmteile deren Source nicht geändert wurde seit Jahren perfekt läuft auf einmal nach irgend einem Update von xbase Zicken macht? Da es dabei noch die Buchhaltung ist macht es nicht einfacher.

Aber du hast recht ich schreibe mal an Alaska. Was ich bis zur Antwort von Alaska den Kunden sage weis ich nicht. Ich habe gehoft dass jemand einen Tip hat oder auch schon über dieses Problem gestossen ist.

Gruss Carlo

Naja, Jan,
nicht zu groß? Er hat 0,00 und will die mittels str() mit einer(!) Nachkommastelle darstellen!
Sollte eigentlich kein Problem sein - aber ich habe noch die 1.9 SL1 im Einsatz.

Carlo,
was passiert, wenn Du statt str() mit transform() arbeitest?

Viele Grüße,
Martin

Hallo Martin,

OK, das könnte man so sehen. Aber lt. Hilfe von Alaska wird gerundet, wenn die angefragten Dezimalstellen kleiner sind als die tatsächlichen. Aber ja, das wäre mal eine Idee, den errechneten Wert erstmal mit Round() auf 1 Nachkommastelle zu bringen, und danach erst in Str() einzusetzen.

Jan

Laut Alaska... schon.
Aber - es wurde ja schon Mal Code "gebrochen". Keine Ahnung, ob es das ist. Ich kann es auch nicht testen/provozieren, da ich keine aktuelle Version habe.
Ist halt nur eine Idee...

Viele Grüße,
Martin

Hallo Martin

das dumme ist dass sich der Fehler nicht gezielt herbeiführen lässt.
Vorallem wurden die "Problemzeilen" in den letzten Jahren sicher mehrere Mio mal Durchlaufen immer ok .... ich kann doch nicht alle str() gegen transform() austauschen....
z.b. es passiert beim Posten 5 nach Neustart kann der Posten 5 aber problemlos 20 Mal aufgerufen werden ohne ein Problem.
Es trifft auch unterschiedlichen Stellen wie ? str() oder @ .... say str() oder str() + str() + str()

Als gemeinsamkeit sehe ich dass es immer passiert wenn ein Wert berechnet wurde, z.B aus Datenbankfelden oder Mem-Vars auch nach Round() jedoch noch nie in einer Zeile die nur ein Datenbankfeld anzeigt wird. ( str(field->betrag,10,2) )

Gruss Carlo

ramses hat geschrieben: ↑Di, 08. Aug 2017 15:02ich kann doch nicht alle str() gegen transform() austauschen....

in so einem Fall würde ich es per machen. wie die genaue Syntax ist müsste man erarbeiten.

Frage : tritt das Problem auf mehreren/allen PCs auf oder nur auf einer bestimmten Workstation ?

Str() und Transform() haben aber ganz andere Syntax.

Ich würde in so einem Fall nicht auf die Errorsys vertrauen, dass die die division durch 0 abfängt, sondern eine eigene Funktion aufrufen mit beiden Werten, die dies abfängt:
dann würde im Fehlerfall auch eine Zeilennummer in deiner Funktion angezeigt werden und man käme dem Problem näher.

Hallo

@ Jimmy

es sind verschiedene PC's betroffen.


@Hubert

auf die Errorsys bezw. das so abfangen der DIvision durch Null hat viele viele Jahre so funktioniert. Wenn man sich auf das nicht mehr verlassen kann ist das beinahe ein Totalschaden des ganzen Programms würden bedeuten den ganzen Code auf solche Stellen abzusuchen. Das dürfte es doch so nicht sein !?

Gruss Carlo

64-bit ?
Division durch 0.000000000000000000000000000000000000000000000000000111 ?
Wenn der Patch nicht installiert ist passiert das.

Hallo Klaus

welcher Patch?

Gruss Carlo

War das nicht ein Patch für 1.90.xxx ?

Der Zugriff auf die Datenbank erfolgt über ADSDBE.
Xbase-Version 2.0.807
ADS-Version 10.10.0.49 axcws32.dll Version 10.10.0.49

PS: ich sage nicht, dass die Methode über die ErrorSys() nicht ok ist, ich würde es nur nie so machen.

Meine Errorsys() ist stark erweitert um Fehler zu dokumentieren, dabei kam es vor, dass dort auch Fehler entstanden, das wird dann übel
Aber ich hatte ADSDBE und Xbase++ 2.00 übersehen, also vergiss meinen Eintrag einfach

Carlo,
es gibt bzw. gab einen Patch dafür, den ich selbst aber aufgrund einer abgelaufenen Subscription nicht installieren konnten.
Deshalb behelfe ich mich an den Stellen wo es passiert mit Val(STR(nWert)).

Das war für 1.90.355, PDR 6130 und 6286, beide wurden mit dem Hotfix 36 behoben, dürften also in 2.00.x gar keine Rolle mehr spielen.

sorry hatte das übersehen das Carlos die 2.0 Version einsetzt.
vermute aber das sich das Problem trotzdem in dem Bereich befindet.

PS: ich sage nicht, dass die Methode über die ErrorSys() nicht ok ist, ich würde es nur nie so machen.

Ich vermutlich mit dem Wissen von heute auch nicht mehr.
Wenn dies jetzt plötzlich nicht mehr geht und solche Zeilen zu sporadischen Fehlern führen ist das nicht mehr handelbar.
An vielen Stellen in den Programmen sind Divisionen, wie Füllstandsberechnungen, Kapazitätsberechnung uva. da ist eine Div durch 0 absolut normal und darf doch nicht plötzlich zu Fehlern führen. Vorallem kann man schlicht nicht hingehen und nach Jahren den gesamten Code vom xxxxxxx Zeilen überarbeiten.

Ich weiss momentan wirklich nicht mehr weiter. Mein aktuelles Konzept "aktuelle Tools" verwenden scheint zum Totalschaden zu werden ......

Gruss Carlo

Da der Fehler nur selten Auftritt, musst du die Errorsys um Infos erweitern, z.b. immer fortschreiben, oder den Dateinamen um Datum und Uhrzeit (Rechnername) ergänzen.
Dann würde ich in der Zeile die die DIV 0 behandeln soll in der ErrorSys einen LOG einbauen, damit du sieht, er kam da mit ... Werten an und gab ... zurück.

Betrifft es nur Datenbankfelder oder auch Berechnungen mit local Variablen ?

Betrifft es nur die ADSDBE oder auch DBF...

ramses hat geschrieben: ↑Di, 08. Aug 2017 13:36

Code: Alles auswählen

?? str(field->skontoabz/(field->skontober/100),10,1)

Zerlege die Zeile doch mal in mehrere und schaue was dann herauskommt, z.B.:

Hallo Hubert, Hallo Roland

das tut meine Errorsys bereits. Sie schreibt sämtliche Infos, Username, Exeversion, Verzeichnisse, geöffnete DBF's Index aktuelle DBF, Index, recno() usw. usw. weg.

Betrifft es nur Datenbankfelder oder auch Berechnungen mit local Variablen ?

Das kann ich nicht bestimmen. Einzig es folgt nach einer Berechnung auch über Locale Vars.

Ich habe heute den ganzen Tag versucht den Fehler zu provozieren .... ohne Erfolg.... einzig hat sich das Test-Programm unter dem Debugger einige male von 6MB auf 160MB aufgebläht und ist dann mit einer xppfatal gecrasht ....


Gruss Carlo

Carlo - wie in dem anderen Beitrag erwähnt, versuche es doch einmal mit einer Funktion die Dir den String zurückgibt. Ich meine, dass es irgendwie möglich sein müsste eine (weitere) andere Fehlermeldung zu produzieren die einen zusätzlichen Hinweis auf den Ursprung des Übels gibt. Und damit Str(...) entlastet.

So dass in der Ausgabezeile nur noch die String-Var ausgegeben wird
?? cErgebnis

( https://xbaseforum.de/viewtopic.php?f=9 ... 41#p115038 )


Habe interessehalber meinen gesamten Code grob durchforstet,
3x ? str(... (nur in 3 Testprogrammen)
0x ?? str(...
Ich verwende also str() so gut wie nicht in Zeilen mit ? oder ??

ramses hat geschrieben: ↑Di, 08. Aug 2017 19:14es sind verschiedene PC's betroffen.

OK ... aber nicht auf alle PCs und nicht immer ... dann konntest du es ja simulieren und den Fehler finden.

ihr geht alle auf das STR() raus aber IMHO passiert schon vorher "etwas" wonach ich schauen würde.
ich habe ein Logbuch wo ich in solchen Fällen nachsehe was der User wann vorher gemacht hat.

Szenario :
User öffnet DBF um in einer Maske was einzugeben.
jetzt kommt ein Anruf der eine ganze Zeit lang dauert -> kein Logbuch Bewegung
nach dem Anruf gibt er weiter Daten ein und klickt auf "save" und bekommt einen Absturz mit "unsinniger" Meldung.

die Meldung alleine bringt einen evtl. noch nicht weiter aber wenn man in das Logbuch sieht käme man auf die Idee ob ein Timeout vorliegen könnte der Schlussendlich zum Fehler führt.

also suche mal im Umfeld vor dem Fehler ob du da Gemeinsamkeiten findest was den Fehler provozieren könnte.

Nachtrag :

ich sehe gerade in "Seltsames Verhalten Version 817" den letzten Beitrag mit "Index" ...
es wäre ein Test wert bei den Betreffenden DBF ein Index mit STR(Feld) aufzubauen um zu sehen ob es ohne Fehler durchläuft. zumindest wäre man dann sicher das die Daten OK sind und kein Mist rein gekommen ist (z.b. defekter Cluster auf einer HDD)

Hallo Jimmy, Hallo Roland

die Gemeinsamkeit ist dass:

-- ein Ergebiss aus einer Rechnung mit einem nummerischen Datenbankfeld (über ADSDBE) in str() zum Crash führt.
-- es in einer Schlaufe passiert in welcher z.B. Rechnungen gedruckt werden, nach x Rechnungen ---> BUMM
-- ein in str() in vielfacher Kombi geschiet z.b. ? str() oder auch arr[1] := str() usw. usw.


Der Support hat verschiedene Vermutungen. Besonders eigene DLL-Funktionsaufrufe stehen im Focus,
Das gleiche Problem ( ADS - str() ) ist anscheinend auch schon aufgetreten jedoch hatte der Betroffene Alaska nicht mehr über die Lösung/Ursache informiert.

Gruss Carlo

Hallo Carlo

ich wiederhole mich...
hast Du getestet, was passiert wenn Du die Berechnungen usw. vor der Ausgabe mit ?/?? Dann NUR die String-Var mit den ausgiebst. Da muss sich was ändern...
Nur Du kannst das testen, sonst kann ich Dir kein bishchen weiterhelfen...

Ev. auch die Ausdrücke in Str(...) nochmal zusätzlich in Klammern stellen.

?? str(field->skontoabz/(field->skontober/100),10,1)
|
V
?? str( ( field->skontoabz / ( field->skontober / 100 ) ) , 10 , 1 )

Hallo Roland

Ja das habe ich getestet.

z.B.
a := field->skontoabz/(field->skontober/100)
? str(a,10,1) --> BUMM

oder

a := ( field->skontoabz/(field->skontober/100) )
? str(a,10,1) --> BUMM


Gruss Carlo