We have seen this with numeric data. For instance, if the data type is n(7,4), VFP allows you to programatically enter a value that is not really 7,4 but actually 7,3. An n(7,4) field should be 7 total digits, including the decimal point, so the max should be 99.9999. VFP has always allowed you to programatically provide an equal number of digits, with fewer decimal places, like this:
>

>replace nfield with 999.999
>

>
>VFP itself allows updating and accessing data from a field containing this value, but the VFP OLEDB provider does not allow either. The typing is stricter to ensure proper interoperability with ADO, ADO.Net, SQL Linked Servers, DTS, etc.
>
>If you have a field like this, you will get the EFAIL error. The workaround is to increase the field size to properly accomodate the data it actually contains.
>
>For example, a value of 123.456 would cause an error in the provider if the field datatype is n(7,4) but will work OK with a type of n(8,4).
>
>I hope I have made this clear enough!



Hi Jim,

I finally got a chance to look back at this and you hit the nail right on the head. There are several records that have values of 109 and 113 in fields defined as n(4,1)
If I change the values in the 29 offending records, or increase the field to n(5,1), there are no more problems.


Thanks again for your help,

- Brian