>
SPT can be used in the middle tier for Updates, Inserts, and Deletes and integrated with business logic.
>

The logic that actually PERFORMS the Updates, Inserts, Deletes, and Queries should be manifested as stored procs.. The calls to these items, either as SPT or via ADO can be on the middle tier...

>
Also with MTS (something I'm currently looking into), the SetComplete and SetAbort functions can make Transactions much easier to handle. With Stored Procedures, this could be a nightmare with multiple databases / backends and could affect scalabilty.
>

If the calls are in the middle tier components that are hosted by MTS, where is the problem? Please define this position in more detail...


>
Also, clients who have a current or potential need for SQL Server dread the idea of hiring a DBA for SP coding and maintenance - they want the developer to do it all *bg*. While a DBA may be required for other reasons, IMHO, application-specific code (e.g. Stored Procedures) should be handled be the developer.
>

Often, the developer can function as the DBA. This is more of an argument in semantics...

>
While there are performance gains associated with SPs, I think it's a bad idea to rely on them to the extent you have indicated here and on many other past threads.
>

While this may be your opinion, the basis with which you make your conclusions are general at best.

Whether you render SQL from a middle tier component or make calls from a middle-tier component to a SP that hosts the SQL, there is no effect on the issues you bring forth in your argument. Multiple DB's??? Use linked servers. Then again, often, this is more of a perceived problem than an actual problem. The fact is, SP's solve more problems than they create. In reality, SP's don't create problems. Rather, they are just different. It is a matter of LEARNING how to use SP's...


Back to you.....