Problem beim schreiben von 0.00 Werten über ADS in eine DBF

[ichbindabei]

Hallo zusammen

Ich haben hier eine XBase++ Anwendung die früher auf einem 32 Bit Windows XP lief.
Mitlerweile bin ich auf einen 64 Bit Windows Server 2003 umgezogen.
Das Problem was ich jetzt habe ist, dass ich früher ohne Probleme 0-Werte über einen ADS-Server in eine DBF schreiben konnten.
Auf dem neuem System bekommen ich einen Numerischer Überlauf.
Der Fehler tritt nur dann auf, wenn ich das Programm auf einem 64 Bit System laufen lasse.
Die komplette Fehlermeldung beim "Fieldput" lautet:

Numerischer Überlauf beim Schreiben in
Datenbank TEST;Feld 27;Wert=0.00

Hat irgendwer eine Idee wie man das Problem lösen kann?

Vielen Dank im Vorraus

[Rolf Ramacher]

Hi

ich habe zwar kein 64-Bit-System - aber könntest du nicht vorher den Wert abfragen. wenn Null - mache nichts

[Jan]

Moin Rolf,

aber das ändert ja nichts an dem Problem von Philip - warum werden 0-Werte abgelehnt auf 64-bit?

Jan

[Koverhage]

Hallo,

ich glaube nicht das der Null Wert das Problem darstellt. Es ist letztendlich eine Folge von

siehe hier: http://www.xbaseforum.de/viewtopic.php? ... ion#p49458

[Koverhage]

Jan,

wie gesagt wird da nichts abgelehnt. Meines Erachtens müsste Alaska eine Patch raus bringen, bei dem das Problem
mit der Division durch 0 gelöst ist.
Wenn man sich das Ergebnis einer solchen Operation ansieht, ist dieses augenscheinlich 0, aber eben intern nicht.

[brandelh]

Womit wieder einmal der Hinweis fällig ist, bitte die fehlerhafte Zeile und die genaue Felddefinition angeben, sonst kann man nur raten

[ichbindabei]

Hallo nochmal

Also was ich gerade herausgefunden habe ist, dass str(0.00) schon eine länge von 13 hat.
Wenn ich mit der 0.00 dann auch noch rechne(zum Beispiel mal 0.00) dann hat str(von Ergebniss) schon eine länge von 23

Code: Alles auswählen

local t := 0.00
local r := 0.00

? len(str(t))  //Ausgabe = 13

t:= t*r
? len(str(t))  //Ausgabe = 23

r:= r*r
? len(str(r))  //Ausgabe =75

Diese werte sind dann vermutlich auch zu lang um in mein Datenbank-Feld das eine länge von 16 geschrieben zu werden.

[Rolf Ramacher]

Hi

das Feld welches beschrieben werden soll, ist dies numerisch ? und welche Größe mit Nachkommastelle ?

[ichbindabei]

Es sind meherer Felder, die aber alle numerich sind
eines hat zum Beispiel eine länge von 15 und 2 Decimalstellen

[Tom]

Ich hatte dieses Phänomen auch mal, mit DBFNTX. Ich habe (sinngemäß, der Code war ein anderer) das hier gemacht:

REPLACE ALL FELD3 WITH (FELD1/FELD2)*100

Im Fall, dass FELD2 0.00 war, gab es den Fehler "Länge des Datenbankfeldes wurde überschritten". In der Fehlerbeschreibung stand aber als zu ersetzender Wert "0.00".

So ging es dann:

REPLACE ALL FELD3 WITH Val(Str(FELD1/FELD2)*100,9,5))

Natürlich liegt hier prinzipiell ein Fehler vor. Richtiger wäre das hier:

REPLACE FELD3 WITH (FELD1/FELD2)*100 FOR FELD2 > 0.00, FELD3 WITH 0.00 FOR FELD2 = 0.00

Tatsächlich fängt das Fehlersystem (also meines) die Division durch Null sonst korrekt ab. Das Ergebnis ist ja auch Null. Aber eben eine sehr, sehr lange Null.

[brandelh]

Hi,

wenn es ein numerisches Feld ist, dürften die verschiedenen Längen von str() keine Rolle spielen,
auch wenn diese sehr seltsam sind ... bei str() sollte man grundsätzlich die gewünschte Länge angeben.

Unter Win 7 64-Bit erhalte ich mit diesem Code (OHNE ADS)

Code: Alles auswählen

proc main()
    ? str(2), len(str(2))
    ? str(2.2), len(str(2.2))
    ? str(2.2/100*100), len(str(2.2/100*100))
return

diese Ausgabe:

Code: Alles auswählen

         2         10
         2.2         12
         2.20         13

somit immer 10 Stellen vor dem Komma, der Rest ist variabel.

[ichbindabei]

Vielen Dank an alle
Ich habe grade eine Lösung gefunden
Ich mache folgendes

Code: Alles auswählen

local wert := 0.00
local t := 0.00
wert := wert * t
? len(str(wert)) //Ausgabe = 23

wert := val(str(wert)) 

? len(str(wert)) //Ausgabe = 13

anschließend kann ich den Wert dann auch wieder in die Datenbank schreiben.