Replace question and table precision

* make sure there are no DBCs open
create cursor zoot (zz n(3,1))
append blank
replace zz with 9.9
? zz && prints 9.9
replace zz with 999
? zz && prints 999


The last replace command should not work, but it does. Why? I've learned
from experience that VFP is pretty sloppy about numeric fields if the table
is not associated with a DBC, but I figured they would have fixed this by
now? Is this left in for legacy purposes?

Fred
Wed Aug 17 20:35:08 CDT 2005

Probably for legacy reasons, but it may have to do with the fact that
numeric fields are stored as plain text, not as a binary value.

--
Fred
Microsoft Visual FoxPro MVP


"Ook" <MSNews@emberts.UpYoursSpammer.emberts.com> wrote in message
news:exhmXd4oFHA.1948@TK2MSFTNGP12.phx.gbl...
>* make sure there are no DBCs open
> create cursor zoot (zz n(3,1))
> append blank
> replace zz with 9.9
> ? zz && prints 9.9
> replace zz with 999
> ? zz && prints 999
>
>
> The last replace command should not work, but it does. Why? I've learned
> from experience that VFP is pretty sloppy about numeric fields if the
> table is not associated with a DBC, but I figured they would have fixed
> this by now? Is this left in for legacy purposes?
>

Ook
Thu Aug 18 10:24:46 CDT 2005

I would have thought that VFP would validate the datatype and precision
before just blindly stuffing it in the table. I also thought that after all
these years Microsoft would have fixed this. This, BTW, breaks things like
accessing the data via oledb. We are converting a large app to use a dot net
data layer, and when it finds data that does not match the format that the
DBF says it should be it throws an error. Our dot net experts are still
trying to figure out how to stop that from happening.

And I believe I was wrong about not being able to do this if the DBF is
associated with a DBC. Last night I tried it and it didn't work, but this
morning I did it differently and it worked, go figure?


"Fred Taylor" <ftaylor@mvps.org!REMOVE> wrote in message
news:%23X7dOO5oFHA.3364@tk2msftngp13.phx.gbl...
> Probably for legacy reasons, but it may have to do with the fact that
> numeric fields are stored as plain text, not as a binary value.
>
> --
> Fred
> Microsoft Visual FoxPro MVP
>
>
> "Ook" <MSNews@emberts.UpYoursSpammer.emberts.com> wrote in message
> news:exhmXd4oFHA.1948@TK2MSFTNGP12.phx.gbl...
>>* make sure there are no DBCs open
>> create cursor zoot (zz n(3,1))
>> append blank
>> replace zz with 9.9
>> ? zz && prints 9.9
>> replace zz with 999
>> ? zz && prints 999
>>
>>
>> The last replace command should not work, but it does. Why? I've learned
>> from experience that VFP is pretty sloppy about numeric fields if the
>> table is not associated with a DBC, but I figured they would have fixed
>> this by now? Is this left in for legacy purposes?
>>
>
>

Dan
Thu Aug 18 11:40:27 CDT 2005

Blame Wayne Ratliff.

xBase has been sloppy about numbers since dBase II on CP/M. Exactly this
behavior can royally muck up data dictionary programs using COPY STRU
EXE/CREATE FROM. Of course since the advent of CREATE/ALTER TABLE, who uses
them? <g>

Dan

Ook wrote:
> * make sure there are no DBCs open
> create cursor zoot (zz n(3,1))
> append blank
> replace zz with 9.9
> ? zz && prints 9.9
> replace zz with 999
> ? zz && prints 999
>
>
> The last replace command should not work, but it does. Why? I've
> learned from experience that VFP is pretty sloppy about numeric
> fields if the table is not associated with a DBC, but I figured they
> would have fixed this by now? Is this left in for legacy purposes?

Anders
Thu Aug 18 11:50:25 CDT 2005

That means you should add 1 to the precision, doesn't it? Numeric(3,1) in
xbase means 999 to 0.9. That's what the DBF says if you know the language
<g>.
-Anders


Den 05-08-18 17.24, i artikeln uTnyRuApFHA.3244@TK2MSFTNGP09.phx.gbl, skrev
"Ook" <no usenet spam at zoot al dot com>:

> I would have thought that VFP would validate the datatype and precision
> before just blindly stuffing it in the table. I also thought that after all
> these years Microsoft would have fixed this. This, BTW, breaks things like
> accessing the data via oledb. We are converting a large app to use a dot net
> data layer, and when it finds data that does not match the format that the
> DBF says it should be it throws an error. Our dot net experts are still
> trying to figure out how to stop that from happening.
>
> And I believe I was wrong about not being able to do this if the DBF is
> associated with a DBC. Last night I tried it and it didn't work, but this
> morning I did it differently and it worked, go figure?
>
>
> "Fred Taylor" <ftaylor@mvps.org!REMOVE> wrote in message
> news:%23X7dOO5oFHA.3364@tk2msftngp13.phx.gbl...
>> Probably for legacy reasons, but it may have to do with the fact that
>> numeric fields are stored as plain text, not as a binary value.
>>
>> --
>> Fred
>> Microsoft Visual FoxPro MVP
>>
>>
>> "Ook" <MSNews@emberts.UpYoursSpammer.emberts.com> wrote in message
>> news:exhmXd4oFHA.1948@TK2MSFTNGP12.phx.gbl...
>>> * make sure there are no DBCs open
>>> create cursor zoot (zz n(3,1))
>>> append blank
>>> replace zz with 9.9
>>> ? zz && prints 9.9
>>> replace zz with 999
>>> ? zz && prints 999
>>>
>>>
>>> The last replace command should not work, but it does. Why? I've learned
>>> from experience that VFP is pretty sloppy about numeric fields if the
>>> table is not associated with a DBC, but I figured they would have fixed
>>> this by now? Is this left in for legacy purposes?
>>>
>>
>>
>
>

Anders
Thu Aug 18 12:02:01 CDT 2005

That means you should add 1 to the precision, doesn't it? Numeric(3,1) in
xbase means 999 to 0.9. That's what the DBF says if you know the language
<g>.
-Anders



Den 05-08-18 17.24, i artikeln uTnyRuApFHA.3244@TK2MSFTNGP09.phx.gbl, skrev
"Ook" <no usenet spam at zoot al dot com>:

> I would have thought that VFP would validate the datatype and precision
> before just blindly stuffing it in the table. I also thought that after all
> these years Microsoft would have fixed this. This, BTW, breaks things like
> accessing the data via oledb. We are converting a large app to use a dot net
> data layer, and when it finds data that does not match the format that the
> DBF says it should be it throws an error. Our dot net experts are still
> trying to figure out how to stop that from happening.
>
> And I believe I was wrong about not being able to do this if the DBF is
> associated with a DBC. Last night I tried it and it didn't work, but this
> morning I did it differently and it worked, go figure?
>
>
> "Fred Taylor" <ftaylor@mvps.org!REMOVE> wrote in message
> news:%23X7dOO5oFHA.3364@tk2msftngp13.phx.gbl...
>> Probably for legacy reasons, but it may have to do with the fact that
>> numeric fields are stored as plain text, not as a binary value.
>>
>> --
>> Fred
>> Microsoft Visual FoxPro MVP
>>
>>
>> "Ook" <MSNews@emberts.UpYoursSpammer.emberts.com> wrote in message
>> news:exhmXd4oFHA.1948@TK2MSFTNGP12.phx.gbl...
>>> * make sure there are no DBCs open
>>> create cursor zoot (zz n(3,1))
>>> append blank
>>> replace zz with 9.9
>>> ? zz && prints 9.9
>>> replace zz with 999
>>> ? zz && prints 999
>>>
>>>
>>> The last replace command should not work, but it does. Why? I've learned
>>> from experience that VFP is pretty sloppy about numeric fields if the
>>> table is not associated with a DBC, but I figured they would have fixed
>>> this by now? Is this left in for legacy purposes?
>>>
>>
>>
>
>