Länge des Datenbankfeldes wurde überschritten

[Werner]

Hallo!

Ich habe in einer DBF.Datenbank das Feld: USZHOECHST wie folgt definiert:

Feldname Feldtyp Länge Dez Index

USZHOECHST Numerisch 7 2 N

Während der Berechnung wird diesem Feld mit REPLACE ein (mir unbekannter) Wert zugewiesen, der folgende Fehlermeldung auslöst:

Fehler BASE/8029
Beschreibung: Länge des Datenbankfeldes wurde überschritten
Operation: <USZHOECHST>:=<0.00>
Thread ID: 1

Wenn der zuzuweisende Wert > 9999.99 wäre, z.B. 10000.00, würde die Datenbanklänge natürlich überschritten, aber dann käme dies auch in der entsprechenden Fehlermeldung mit: <USZHOECHST>:=<10000.00> zum Ausdruck.

Wieso die Länge des Datenbankfeldes (s.o.) mit <0.00> überschritten werden kann, ist mir schleierhaft! Versuche mit 0.000001 oder -0.00 haben auch nichts gebracht!

Kann mir jemand einen Tipp geben, durch welchen Wert die oben beschriebene Fehlermeldung auslöst werden kann, so dass ich diesen Wert ggf. vor der Auslösung der obigen Fehlermeldung abfangen könnte?

Vielen Dank im Voraus!

Gruß Werner

[georg]

Hallo, Werner -


prüfe doch, ob der Wert unter dem kleinsten oder über dem grössten möglichen Wert liegt. Wenn ja, kurze Anzeige eines Hinweises (mit dem Wert).

[Koverhage]

ich behaupte mal Windows 7, 64 bit Maschine Division durch 0 oder
das hatte ich jetzt erst, das Feld ist 0,000 hat aber irgendwo noch viele Nachkommastellen, wobei ich reinen Round(nwert,3) hatte und trotzdem
mehr nachkommastellen

deshalb dann val(str(ergebnis))

[brandelh]

Nachkommastellen spielen für die Fehlermeldung keine Rolle. Nur wenn die Vorkommastellen überschritten würden, wäre die Meldung plausibel ...

[Wolfgang Ciriack]

Ich tippe, wie Klaus, auf Division durch 0 mit Win7.

[Koverhage]

Hubert, probier es aus und übertrage den Wert z.B. 0.0000000001

[brandelh]

Ich bin vorsichtiger und sage ... "Es DÜRFTE keine Rolle spielen ..."

Aber hier ist mein Testprogramm, das bei meinem Windows 7 Pro 64bit problemlos durchläuft und die erwartete DBF generiert ...

Code: Alles auswählen

#include "Gra.ch"
#include "Xbp.ch"
#include "Common.ch"

proc main
   local x

   dbcreate("test",{{ "Txt","c",10,0},;
                    { "Zahl","n",7,2},;
                    { "LONG","n",7,0} })

   use test exclusive alias db
   ? "Start"
   for x := 1 to 1000
      append blank
      replace db->txt  with var2char(x)
      replace db->zahl with x+0.00000000001
      replace db->long with x+0.00000000001
   next
   ? "Ende"
   append blank
   x := 0.00000000001
   replace db->txt  with var2char(x)
   replace db->zahl with x
   replace db->long with x
   ? "OK ?"
   close db
   inkey(0)
return

[Jan]

Eine Falle dabei sind Negativwerte. Die benötigen eine Stelle mehr für das -Zeichen. Da bleibt dann eine Stelle weniger für die Ziffern über.

Jan

[Koverhage]

Ich kann jetzt auch nicht sagen ab wie viel Stellen das passiert. Die sieht man ja nicht.
Ich habe auf jeden Fall erst vor ein paar Tagen mit folgenden (länger) gekämpft :

nErgebnis := Round(Wert,3)
if nErgebnis > 0.001 .or nErgebnis < -0.001
nAdd := 0
endif
Leider war nErgebnis > oder < obwohl man das in der Anzeige mit STR nicht gesehen hat und durch Round
das Ergebnis auf jeden Fall nur 3 Nachkommastellen haben dürfte.
Nach einem Val(str(nErgebnis)) waren die Probleme behoben.

[UliTs]

...und durch Round das Ergebnis auf jeden Fall nur 3 Nachkommastellen haben dürfte...

Zahlen mit Nachkommastellen sind bei xBase++ immer Floating-Zahlen.
Das heißt, sie haben immer eine bestimmte Anzahl an Stellen, die man nicht ändern kann!

Das Problem ist, das man im Binär-System selbst so einfache Zahlen wie 0,1 und damit auch 0,001 nicht exakt darstellen kann

Uli

[Werner]

Hallo liebe Kollegen, hier ist noch einmal der Fragesteller zu dem o.g. Problem!

Das war ja ein richtiger 'wisdom-storm', den ihr da abgefeuert habt! Und das sozusagen über Nacht!

Ich möchte mich ganz herzlich bei jedem von ihnen bedanken, der mir geantwortet hat!

Ich denke, dass der Hinweis auf Windows 7 auf der 64-Bit-Maschine meinem Problem am nächsten kommt: Hier könnte im Hintergrund tatsächlich eine (fiktive) Division durch Null eine Rolle gespielt haben!

Aufgrund der gezielten Hinweise habe ich jetzt versucht, eine solche mögliche Fehlerquelle im Vorfeld der Berechnung abzufangen! Ich warte jetzt einmal ab, was der Kunde dazu sagt!

Nochmals vielen Dank! Und bis zum nächsten Mal!

Gruß Werner