Quote
"try sending the stored procedure with the parameters as literals in the commandstring. IOW, don't use VFP's ability to parameterize the commandstring."

So your saying that this:

"exec moveStudentIn '"+ lcStudentID + "', '"+ lcHall +"', "+ lcRoom +", '" + lcDate + "', "+iif(lbToSingle,'1','0')+", "+alltrim(str(piCurrentPeriod))

is faster than this:

"exec moveStudentIn ?lcStudentID, ?lcHall, ?lcRoom, ?lcDate, ?lbToSingle, ?piCurrentPeriod"


??



>>> the main reason for it was not a full optimization of SPT in SQL Server.
>
>I can't infer much from this. To say that VFP is not fully optimizied is too vague of a statement. If you friend is worried about the use of sp_executesql, try sending the stored procedure with the parameters as literals in the commandstring. IOW, don't use VFP's ability to parameterize the commandstring.
>
>4 batches per ms = 4000 batches per second. Wow. That's a lot. Any idea of the hardware that he's running on? I'm also pretty sure that you couldn't claim that that's the kind of performance you should get from all applications that use SQL Server as a data store.
>
>Given the right circumstances, I don't see why you couldn't get that from VFP? I assume that BizTalk uses OLEDB to communicate with SQL Server. OLEDB reads and writes the native wire protocol, TDS and so does ODBC. I'd be wary if ADO was in the picture. It's very heavy.
>
>-Mike