>Michael,
>
>>> You also get the same effect if you try entering 17 digits into the
>>> field in the browse window (at least with VfP 5) 16 digits or less
>>> are ok though !
>
>> Playing further - with a N(20,0) field, it looks like only the first
>> 16 digits are retained, all subsequent digits in numbers 17, 18, 19 &
>> 20 digits long are set to 0.
>
>This is normal because VFP stores numeric as 8 bytes in memory. Some numbers do not have an exact (ASign) a * (10 ^ (BSign * b)) representation because ASign (positive or negative) takes one bit, BSign (positive or negative) takes one bit, b takes several bits, and thus there are not enough bits left over to have exact represntation of large integers in memory. The number stored in memory represents a range of number and VFP *seems* to use 0 as the trailing numbers (which actually makes sense).
>
>The moral of the story. Even if you can store the exact representation of large integers (numbers) in a table (one byte per number or sign), they will give you some problems if you have to perform any type on calculation.
>
>Why do you use such large numbers? If you don't use them for any calculation, you may want to store them as character fields with the appropriate input mask. If you perform calculations on them and you need something better than the VFP precision, you can store them as character and develop your own Add, Substract, Multiply and Divide operation. Drop me a line at Daniel.Rouleau@MetroIS.com if you need hints on how to build these functions.
>
>Daniel

Thanks for the info & offer. I'd guessed it was something like that - with numbers over 333... it's not only 0's put in, so I'd assumed it was related to the method of integer storage. (It was too late to post further observations, by then).

I don't actually use numbers that big. I thought I'd had a similar problem to the original post & tried to create a table to run a little test & ran into the above - I posted the comments to let Brenda know that it wasn't only text boxes.