It turns out, I thought the datatype was numeric, but it is varchar, so I tried passing up the raw string from vfp, casting it, etc. and the string was getting truncated to 4 decimals.... I wound up using a remote view, and it now passes the entire string, as it should. I just hate not knowing why the spt didn't work.... Oh well, next fire please!


>>>>I am having an issue updating a SQL Server table with a converted string. I pull records that may have lat/lon in somr, nad others that need to be geocoded. I get the lat/lon from a google map, which gives me 8 decimals. I am attempting to update the SQL record using Sqlexec and update, but the number of decimals is getting truncated. Here is a snippet of what I am doing:
>>>>lnlat=val(lclat) && might be something like 35.064049
>>>>SQLEXEC(_screen.dsn,'update dbo.incident set latitude=?lnlat where dbo.incident.case_number=?lccaseno')
>>>>If I query SQL again, the stored value is 35.064, yet other records may show 5 decimals....
>>>>
>>>>
>>>>Does anyone know what is going on?
>>>
>>>Did you try to cast to the correct type in VFP side first and may be in the update string also
>>>update Incident set lattitude = cast(?lnLat as decimal(12,5))
>>>
>>>??
>>Yes, I tried both float and decimal and ?val(lclat). The cast statement didn't do anything more than the val() function. There must be some function that will allow the extra decimals....
>
>Have you verified what is sent to SQL Server by running SQL Profiler?
>
>Also, what is the type of the values in SQL Server?
>
>And did you do
>

>lnLat = cast(... as N(20,5)) 
>
>sqlexec(...)
>