It is in the Visual Foxpro section, the thread id is 1140442.

>Could you point me to this thread.
>
>>Yes, the stored procedure always faster thread was a little disappointing if you ask me. There was maybe only one other person that ran your test and posted results. I ran the same test and the stored procedure always runs 20% faster. I ran the test many times, up to 100000 iterations each. For 100000 iterations, the dynamic sql takes 52.39 seconds versus 41.36 seconds (for 10000, it was 5.2 versus 4.2).
>>
>>Anyhow, my point isn't that stored procedures are always faster. But for complicated inserts / batch updates, it would generally be better handled all on the database server. One of the main advanatages of course is just cutting out the network traffic (one call to the server versus 1000 calls).
>>
>>
>>>>You can keep a counter and only send updates every 100 commands for example (just build a string with all the commands, reset the counter and the string after you have sent the update). I have done this and it works OK, but you may need to experiment with the counter to find the best performance.
>>>>
>>>>I have turned on profiler (SQL Server) and examined the commands that are generated when doing updates with remote views. Most of this code is pretty tight, so it may be more trouble than it is worth to convert to SPT.
>>>>
>>>>I haven't studied your code in detail, but if you want the optimal peformance I would think that you should be doing these updates with a stored procedure (especially when doing batch updates / inserts).
>>>
>>>Ummm. Stored procedures are not necessarily faster. I called a stored procedure with a parameter that did the same query as a "dynamic" query I sent with the parameter and the stored procedure took 2x longer.
>>>
>>>Check out the stored procedure always faster thread.