"Ungültiger numerischer Wert für Operation" - wieder mal

Konzeptionelles, Technisches, Termine, Fragen zum Hersteller usw.

Moderator: Moderatoren

Antworten
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:

"Ungültiger numerischer Wert für Operation" - wieder mal

Beitrag 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äß:

Code: Alles auswählen

oDo:feldname := Str(aArray[Element][Element], 9)
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

Code: Alles auswählen

aArray[Element][Element]
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

Code: Alles auswählen

Str(Round(aArray[Element][Element], 0), 9)
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:

Code: Alles auswählen

Str(Val(Var2Char((aArray[Element][Element])), 9)
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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: "Ungültiger numerischer Wert für Operation" - wieder mal

Beitrag 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.
Gruß
Hubert
Benutzeravatar
Frank Grossheinrich
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 142
Registriert: Fr, 31. Mär 2017 15:06
Wohnort: Eschborn
Hat sich bedankt: 5 Mal
Danksagung erhalten: 81 Mal
Kontaktdaten:

Re: "Ungültiger numerischer Wert für Operation" - wieder mal

Beitrag von Frank Grossheinrich »

Hallo Jan,

spätestens bei dem Wort "reproduzierbar" hast du meine volle Aufmerksamkeit.
Haben will!

Grüße, Frank
We love Xbase++, and you?
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: "Ungültiger numerischer Wert für Operation" - wieder mal

Beitrag 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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Frank Grossheinrich
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 142
Registriert: Fr, 31. Mär 2017 15:06
Wohnort: Eschborn
Hat sich bedankt: 5 Mal
Danksagung erhalten: 81 Mal
Kontaktdaten:

Re: "Ungültiger numerischer Wert für Operation" - wieder mal

Beitrag 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
We love Xbase++, and you?
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: "Ungültiger numerischer Wert für Operation" - wieder mal

Beitrag 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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2828
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Hat sich bedankt: 259 Mal
Danksagung erhalten: 12 Mal
Kontaktdaten:

Re: "Ungültiger numerischer Wert für Operation" - wieder mal

Beitrag 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?
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
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: "Ungültiger numerischer Wert für Operation" - wieder mal

Beitrag 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;Prfen 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.
Valar Morghulis

Gruss Carlo
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: "Ungültiger numerischer Wert für Operation" - wieder mal

Beitrag 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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
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: "Ungültiger numerischer Wert für Operation" - wieder mal

Beitrag von ramses »

Hallo Jan

aber du holst dir die Daten aus der DBF. Wenn diese nun "verseucht" im Array stehen ....
Valar Morghulis

Gruss Carlo
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: "Ungültiger numerischer Wert für Operation" - wieder mal

Beitrag 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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
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: "Ungültiger numerischer Wert für Operation" - wieder mal

Beitrag 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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Scarmo
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 188
Registriert: Di, 24. Jul 2007 9:17

Re: "Ungültiger numerischer Wert für Operation" - wieder mal

Beitrag 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
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: "Ungültiger numerischer Wert für Operation" - wieder mal

Beitrag 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 ?
Gruß
Hubert
Antworten