>>>>>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.

Right, exactly.