I seem to have found the root cause of the problem but no way to fix...maybe someone has an idea on how to deal with it.

It seems that the client software may be storing text values in numeric fields. I know, it is not supposed to be possible but here is what I found. It seems that when I open the table directly in foxpro, it shows numeric values as for example 1.0000 but some of the numbers are only showing 1 in the field. When I run odbc connection via a remote view, the 1 is showing up as .null. The ones that have 1.0000 are showing up correctly.

Any ideas on how to fix this? I have tried going through their software and resetting the value to 1.0000 and saving it but the same value shows up as 1
Definitely seems to be a bug in their software. But in their software they seem to be correcting it so that they can perform calculations.

I'm open to any ideas here....

Pat.


>I have a situation at a client in which they are running a software system called Cougar Mountain (accounting). According to the vendor, the data files are in dBase IV. I don't want to convert any of the data over to VFP. I just want to modify the data. It seems that when you access the data directly, it creates a vfp compound index file. This is fine since it doesn't cause any problems with their software. The problem arises when you access the dbase IV files directly and it has a memo field. VFP wants to convert it over and will not use the table unless the memo file is converted over. Needless to say, that would cause a problem for their software. The next path I took was to use the dbase IV odbc driver. This isn't working either. It seems that data is being lost. Not records but fields. Alot of the fields are being passed back via spt and they are showing .null. I have verified that the data is there and it is not .null. Any ideas on what is going on and how to fix it
>so that I can keep this client happy? (besides rewriting an entire accounting package in VFP...I tried that already! *GRIN*)
>
>Thanks,
>pat.