converting numeric fields 3

[FOXPROG]

I have a 20 digit numeric field that I want to convert to a string but when I use the str command to put it into a character field it converts it to scientific format. Does anyone know of a string function that will avoid this problem?

 

[JRB-Bldr]

If you look into your VFP Help file for STR() you will see that with no options defined it will default to a 10 digit character representation of the number.

Since you have a 20 digit number, you need to use the Options within the STR() command to make the conversion.

Good Luck,
JRB-Bldr

 

[FOXPROG]

That was the first thing I did but it seems 19 is the limit so a 20 digit number gives me the same result and thoughts?

 

[alvechurchdata]

Help says that the numeric range is - .9999999999E+19 to .9999999999E+20 so it sounds as thogh you've hit an inbuilt limit. I think you're going to have to write your own loop to build up the string one character at a time by repeating a Mod() operation on the number.


Geoff Franklin

http://www.alvechurchdata.co.uk

 

[Olaf Doschke]

In fact a DBF stores N(20) fields as chars in the DBF, you can check that with a hew editor (eg HexEdit.app from Home()+"Tools\Hexedit")

But no the numeric field is handled as a number, which VFP alsway handles as a float (double) anyway (Help says in memory it's 8bytes, that's what a double variable takes). The limitation really is 16 digits, eg try this:

create cursor curTest (nNumeric N(20))
insert into curTest Values (12345678901234567890)

Browsing this you'll see 1.234567891234E+19 and when selecting the field it displays 12345678901234000000. This even only considers 14 decimals accurracy.

create cursor curTest (nNumeric N(19))
insert into curTest Values (1234567890123456789)

Browsing that shows 1234567890123457000

The weakness of this is the memory representation of the number, the N(19) and N(20) fields are capable to store 19 or 20 digits exact, but the digits get lost on the way, as the numeric literal 12345678901234567890 in the code (which actually is text) is lost on the way either already when compiling or when the Insert-SQL is executed, I don't know the exact culprit here.

In fact you have a limitation at the memory level already and thus N(16) is the maximum field that really makes sense. Storing larger numbers, eg telephone numbers or some identifier of a product etc. you better use Character fields.

If somehow you managed to get higher pricision numbers into a N(20) field you should see that in a hexedit of the DBF file. It may be possible to extract the digits with MOD, eg MOD(numericfield,10) will give you the lowest digit.

Bye, Olaf.