>Alexandre,
>
>>Walter you can but as John said this is when the use of SP's make the more sense, remember that multiple round trips have a speed cost, where nothing is processing is just the delay of comunication between the server and the client while if u call a SP that encapsulate all that same call's in just 1 unit it will be faster then SPT, and this is a fact that u can mesure.

>Huh?? Lets say that you have an order with orderlines. And you want to submit the thing into one transaction. One way or another the information has to be send to the server.

BTW, you can pass all the needed SQL code through SPT as well, no problemo. No more rountrips.

>How do you want to do this with a SP?? An example please, I'm curious how you guys think it would be easier and at the same time performing better than SPT .....
>
>If you are talking about the extra SQLCOMMIT(), I don't think anyone would argue this is measurable within a whole transaction.
>
>And even if you've got a case where a SP does perform better and is more logical, my reply was based on the fact that mission critical transactions spanning multiple tables ARE POSSIBLE with SPT. So the argument that an SP has the advantage of wrapping everything into a transaction, is simply not true.
>
>Walter,
>
>
>
>
>
>>
>>>>You're taking it too personally. As are most here.
>>>>
>>>>I'm just looking for somebody to engage Walter's points so I can try to learn something.
>>>>
>>>>OK, here is one reason to use SP:
>>>>
>>>>1) Critical transactions- If you have a scenario where multi-table writes need to be transacted without fail to avoid disastrous consequences, forcing use of a SP is a reliable way to ensure compliance. Example- banking transactions, controlled substance stockkeeping.
>>>>
>>>>Do you agree?
>>>
>>>Perry and John,
>>>
>>>And why are you not able to do that with SPT on a shared connection with a manual transaction set on ??
>>>
>>>Walter,