If it is a parameterized view, yes it uses sp_executesql. If it is not a parameterized view, it just sends the raw sql command.

I assume what you may be getting at is that using sp_executesql basically gives you the advantage that precomile is trying to give you. If so, I have basically come to the same conclusion. I am going to put togther a wiki article on this once I've got all the facts straight.

BOb


>BTW, what is the behavior if you don't use the precompile option? Does it use sp_executesql?
>
>-Mike
>
>>You can enable ODBC tracing to see the calls that VFP is making to ODBC. From that you should be able to determine whether it is VFP or ODBC causing the issue.
>>
>>I believe that the two procs are extended stored procedures.
>>
>>-Mike
>>
>>>I am curious cause VFP is using them, or at least causing them to be used when you set a remove view to 'precompile' and also when you use SQLCompare(). However, it looks like it is using them incorrectly or at least not the most efficient.
>>>
>>>For example, if you set up a remote view with a parameter and set it to precomile, when you use the view then sp_prepexec is used, but when you requery instead of using sp_execute it uses sp_unprep then sp_prepexec again. Which doesn't seem right to me.
>>>
>>>Also, when you use SQLPrePare() and then you use SQLExecute() and only having change the paremeter, once again it uses sp_prepexec. It seems to me it would use sp_execute passing the prep handle and the new parameters. It only seems to use sp_exec if you call sqlexec() again without changing the parameter.
>>>
>>>I wanted to submit this as a bug report bug wanted to be 100% certain how they worked. The weird thing is, they aren't even in master so I can't look at the code.
>>>
>>>BOb
>>>
>>>>Those stored procedures are used by ODBC on the server side. I've never seen any documenation on them.
>>>>
>>>>Any specific reason?
>>>>
>>>>-Mike
>>>>
>>>>>Where can I find documentation on the subject SP's?
>>>>>
>>>>>Thanks,
>>>>>BOb