>>>>I think this, you think that - but the actuality would have to be tested. Don't have the profiler on this machine.
>>>
>>>I'm 99.999% sure the conversion to N(17,0) in VFP will do nothing.
>>
>>But then what's the problem? There's no float or other... the parameter passed is represented as a string in the insert command sent anyway. You'd have a
>>
>>cast(@p15 as numeric(17,0))
>>
>>and the @15 will be mentioned as ...,12345.5494850,... in the parameter list.
>
>The @p15 will be passed as float. So, with adding
>
>select * from myTable where colName = CAST(@p15 as NUMERIC(17,0))
>
>it will execute it correctly in SQL Server and the fact that @p15 is float doesn't matter anymore.
>
>If we will run this command without that cast, e.g.
>
>SELECT * from myTable where colName = @p15 where @p15 is float and the colName is numeric(17,0) we will have implicit conversion in the plan which may be very costly on big tables.

Ah, so you're forcing it to be of certain type SQL side for these reasons. The parameter type is sort of decided ad hoc, and VFP's parser just passes general numerics (as a literal in the parameter list, ergo a generic numeric type) in the most precise notation it can, so I guess it often gets interpreted as a float.