Seite 1 von 1
"Ungültiger numerischer Wert für Operation" - wieder mal
Verfasst: Mo, 09. Nov 2020 12:33
von Jan
Hallo,
wir hatten um diese Fehlermeldung schon mehrere Diskussionen hier im Forum. Bei meinem Kunden bekomme ich diese Fehlermeldung:
Code: Alles auswählen
------------------------------------------------------------------------------
oError:args :
-> VALTYPE: N VALUE:0.00
-> VALTYPE: N VALUE:9
oError:canDefault : .F.
oError:canRetry : .F.
oError:canSubstitute: .T.
oError:cargo : NIL
oError:description : Ungültiger numerischer Wert für Operation
oError:filename :
oError:genCode : 12
oError:operation : str
oError:osCode : 0
oError:severity : 2
oError:subCode : 5
oError:subSystem : BASE
oError:thread : 1
oError:tries : 0
Die Zeile lautet sinngemäß:
Es kann also nicht wie bei Carlo ein Problem mit einem dbf-Header sein, denn hier ist keine dbf im Spiel. Es kann aber auch nichts mit dem DO zu tun haben, denn auch der Aufruf nur der Str()-Konvertierung im Befehlsfenster der Workbench ohne jede Zuweisung zu irgend was bringt dort exakt den gleichen Fehler.
Rufe ich im Befehlsfenster nur ein
auf bekomme ich ganz korrekt ein 0.00 zurück. Das ist also soweit vollkommen in Ordnung.
Der in anderen Diskussionen vorgeschlagene Trick, den Wert erst per
auf 0 Dezimalstellen zu runden und dann die Konvertierung zu machen, bringt nur genau die gleiche Fehlermeldung zustande.
Vermeiden kann ich das, indem ich da noch ein paar Konvertierungen mehr einbaue:
Aber das kann ja nicht wirklich der Sinn der Sache sein. Vor Allem, weil das dann direkt in der nächsten Codezeile mit einem Str() scheppert. Ich kann doch nicht im gesamten Programm alle Str()-Aufrufe dermaßen erweitern. OK, ich könnte schon. Aber das wäre ziemlich stumpfsinnig.
Was dagegen auffällt: Diese Codezeile wird in der Funktion in einer FOR...NEXT-Schleife mehrfach durchlaufen, und später im Code dieser Funktion noch mehrfach. Das klappt alles korrekt. Immer. Aber wenn ich diese Funktion dann ein weiteres mal aufrufe, dann scheppert das. Reproduzierbar. Obwohl alle Werte im Array absolut identisch sind.
Hat da irgend wer eine Idee zu?
Jan
Re: "Ungültiger numerischer Wert für Operation" - wieder mal
Verfasst: Mo, 09. Nov 2020 12:50
von brandelh
Wahrlich seltsam, laut deiner ErrorLog
Code: Alles auswählen
-> VALTYPE: N VALUE:0.00
-> VALTYPE: N VALUE:9
oError:description : Ungültiger numerischer Wert für Operation
oError:filename :
oError:genCode : 12
oError:operation : str
meldet die Funktion STR() den Fehler, die Parameter sind aber vom richtigen TYP ( N / N ), und die Werte sind auch passend.
Wenn du das mit einem kleinen Programm reproduzieren kannst wäre das ein Fall für den Support.
Ich kann mich an solche Fehler aber nicht erinnern.
Re: "Ungültiger numerischer Wert für Operation" - wieder mal
Verfasst: Mo, 09. Nov 2020 13:25
von Frank Grossheinrich
Hallo Jan,
spätestens bei dem Wort "reproduzierbar" hast du meine volle Aufmerksamkeit.
Haben will!
Grüße, Frank
Re: "Ungültiger numerischer Wert für Operation" - wieder mal
Verfasst: Mo, 09. Nov 2020 13:37
von Jan
Frank,
ist mir schon klar. Aber bedenke bitte: Nur weil das im Kundenprogramm reproduzierbar ist heißt das nicht, das ich das auch in einem Sample für Euch hinbekommen kann. Immerhin ist dieses die einzige Stelle in zehntausenden von Codezeilen bei dem Kunden, wo das solche Probleme macht. Da kann also sehr gut irgend etwas anderes, bislang unbekanntes, irgendwie mit rein grätschen.
Jan
Re: "Ungültiger numerischer Wert für Operation" - wieder mal
Verfasst: Mo, 09. Nov 2020 17:45
von Frank Grossheinrich
Hi Jan,
wo kommen die Inhalte aus dem Array her? Sind das Xbase++ berechnete Werte? Oder aus APIs?
Könntest du den Wert aus aArray[Element][Element] einer Variablen zuweisen und dann an STR() übergeben?
Und passiert es nur mit dem Wert 0.00? Oder auch bei anderen Werten?
Das muss sich doch finden lassen ...
Grüße, Jan
Re: "Ungültiger numerischer Wert für Operation" - wieder mal
Verfasst: Mo, 09. Nov 2020 18:10
von Jan
Hallo Frank,
alles in Xbase++ aus eigenen dbf herausgeholt.
Den Wert erst in eine Variable einlesen und dann das Str() darauf zu machen ändert leider überhaupt nichts.
Und scheint tatsächlich so nur bei Wert 0.00 so zu sein. Stehen da höhere Werte drin läuft das korrekt durch.
Ich hatte vorhin schon angefangen daraus ein Sample zu machen für Euch. Aber wie befürchtet - da läuft das natürlich sauber durch. *grmpf* Vorführeffekt.
Jan
Re: "Ungültiger numerischer Wert für Operation" - wieder mal
Verfasst: Mo, 09. Nov 2020 22:49
von UliTs
Jan hat geschrieben: ↑Mo, 09. Nov 2020 18:10...
Den Wert erst in eine Variable einlesen und dann das Str() darauf zu machen ändert leider überhaupt nichts.
Was passiert, wenn du dann 0.01 zur Variablen dazu addierst? Kannst du den Wert dann speichern?
Re: "Ungültiger numerischer Wert für Operation" - wieder mal
Verfasst: Di, 10. Nov 2020 6:02
von ramses
Hallo Jan
mir kommt das irgenwie bekannt vor. Besonders da es nicht ein genereller Fehler ist würde ich doch mal den DBF-Header prüfen.
Ich verwende dazu diese Funktion: (Passt auf unsere DBF's)
Code: Alles auswählen
function u993chkdbfHeader( fname, lMsg )
local buffer,n,a,i,flag
local ret_val := .f.
local nMaxFields := 350
default lMsg to .t.
if file(fname)
handle := fopen( fname, FO_READWRITE ) // read write
if handle < 0
if lMsg
msgbox("CHECK DBF-Header-File: "+fname+" konnte nicht ge”ffnet werden.")
endif
else
buffer := space(32)
i := 0
do while .t.
if fread( handle,@buffer,32 ) != 32
exit
endif
i ++
nMaxFields --
if nMaxFields <= 0
if lMsg
msgbox("CHECK DBF-Header-File: "+fname+" wird abgebrochen.;Feldanazhl ist gr”sser als 350 Eintr„ge;Prfen Sie diese Datei!")
endif
exit
endif
if i = 1 .and. (! substr(buffer,1,1) $ chr(131)+chr(3)+chr(135)+chr(8)+chr(7) ) // 83h/131 = dbase iii mit memo, 3 no memo, 8,7,87h ? ADS
exit
endif
if substr(buffer,1,1) = chr(13) // end from header
exit
endif
if i = 1 // kopfheader
loop
endif
// Feldrecord prüfen
n := 0
flag := .f.
for a = 1 to 11 // Name max 10 + 1 zeichen rest 0 pos 0-9
if substr(buffer,a,1) = chr(0)
n := a
endif
if substr(buffer,a,1) != chr(0) .and. n != 0
buffer := stuff(buffer,a,1,chr(0))
flag := .t.
endif
next
// pos 11 feldtype
for a = 13 to 16
if substr(buffer,a,1) != chr(0)
buffer := stuff(buffer,a,1,chr(0))
flag := .t.
endif
next
for a = 19 to 32
if substr(buffer,a,1) != chr(0)
buffer := stuff(buffer,a,1,chr(0))
flag := .t.
endif
next
if flag
ret_val := .t.
endif
enddo
fclose(handle)
endif
endif
return(ret_val)
Erstell bitte zuerst eine Sicherung der Datei.
Re: "Ungültiger numerischer Wert für Operation" - wieder mal
Verfasst: Di, 10. Nov 2020 6:48
von Jan
Carlo,
wie ich oben schon schrieb: Deine Lösung von damals mit dem Header hilft hier nicht. Weil keine dbf direkt involviert ist. Ich hole da zwar die Daten ab, aber in der fraglichen Zeile findet keinerlei Zugriff auf irgend eine dbf statt.
Jan
Re: "Ungültiger numerischer Wert für Operation" - wieder mal
Verfasst: Di, 10. Nov 2020 6:57
von ramses
Hallo Jan
aber du holst dir die Daten aus der DBF. Wenn diese nun "verseucht" im Array stehen ....
Re: "Ungültiger numerischer Wert für Operation" - wieder mal
Verfasst: Di, 10. Nov 2020 7:58
von Jan
Uli,
interessant. Ich hab das mal so gemacht das ich generell bei der Konvertierung auf den erhaltenen Wert die 0.01 aufaddiere. Der meckert da nicht über das aufaddieren. Aber das Str() scheppert dann doch wieder. Und zwar - Überraschung! - wieder mit der Fehlermeldung mit den beiden numerischen Werten 0.00 und 9. Obwohl das ja jetzt eigentlich 0.01 und 9 sein müssten.
Ich hab das dann mal im Debugger beobachtet: Wenn ich in der Befehlszeile der Workbench das Array aufrufe, dann bekomme ich als Ausgabe korrekt die 0.00. Rufe ich aber das Array auf und addiere da egal was dazu, dann ergibt das im Ausgabefenster weiterhin die 0.00. Das KANN überhaupt nicht so sein. Ist es aber.
Ich habe dann mal dem aktuellen Arrayfeld im Befehlsfenster die 0.00 zugewiesen. Und dann das nochmal aufgerufen mit der Addition. Dann klappt das.
Das heißt, das mich alle Ausgabemöglichkeiten der Workbench anlügen. Das Array {{0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00}, {0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00}} (das ist jetzt ein Aufruf des gesamten Arrays im Befehlsfenster, und dann das Resultat aus dem Ausgabenfenster hier rein kopiert) existiert so gar nicht. Was dann wieder für die Vermutung von Carlo sprechen würde, das die Daten aus der dbf schon falsch übernommen werden. Was aber nicht sichtbar ist weil das programmintern nach außen hin sichtbar korrekt mitgeführt wird.
Ein klein wenig verwirrend das ganze ...
Jan
Re: "Ungültiger numerischer Wert für Operation" - wieder mal
Verfasst: Di, 10. Nov 2020 8:10
von Jan
Ich hab das mal versucht automatisiert umzusetzen. Also in der Richtung
Code: Alles auswählen
IF aArray[nElement][nElement] = 0.00
aArray[nElement][nElement] := 0.00
ENDIF
oDo:feldname := Str(aArray[nElement][nElement], 9)
Nö. Klappt nicht. Weil der in der IF-Abfrage nicht erkennt daß der Inhalt 0.00 ist.
Jan
Re: "Ungültiger numerischer Wert für Operation" - wieder mal
Verfasst: Di, 10. Nov 2020 8:26
von Scarmo
Hallo Jan
Aber klappt es denn mit "if val(str(aArray[nElement][nElement],12,2)) =0"? Oder scheppert's dann beim str(), weil es (offenbar) kein numerischer Wert ist?
Gruss Marco
Re: "Ungültiger numerischer Wert für Operation" - wieder mal
Verfasst: Di, 10. Nov 2020 9:20
von brandelh
Ich würde zur Prüfung eine Funktion MyStr() nutzen, in der vor dem STT() Aufruf auf valtype() geprüft wird.
Dann eventuelle Abweichungen protokollieren.
Auf jeden Fall den Aufruf von Str() nur mit einer localen Variablen, die den Wert aus dem Array bekommen hat.
je einfacher die Zeile, umso größer die Chance dass der Fehler wandert, wobei JAN das ja schon probiert haben soll.
Eine andere Frage, ist die Array Variable vom Typ PRIVAT oder PUBLIC oder LOCAL ?