Hi John:

>>I agree I have not tested with 100 people hitting the system simultaneously, >>which would be a useful test. But then, there are others who have not tested >>at all.

Including me! If I had a dime for every time I've read in a book or periodical about the advantages of using SP's, I'd be a rich man. I'm just going on blind faith. The claimed performance boost comes from the fact that SP are precompiled and waiting for action. Sending SQL statements down the wire and compling and runnning them on the server is not efficient.

>>If you mean that using SPs puts the logic on the server and removes >>complexity at the client, there are lots of ways to do that. Actually it >>might be "better" to place such logic in a 3rd tier rather than the database >>if you are really interested in flexibility.

Only business rules belong in the middle tier because they can change alot. Action queries (update, delete, insert and select statements) belong with the data. Moving them to SP's gives you an additional layer of abstraction and is more of a "data driven" approach to development.

>>It has been mooted that some clients might require SPs. In that case you'd >>use SPs but an fair response would be that SPs are used because they have to >>be, not because they are "superior". Such a response would not label >>others "lousy" either. Others might say they use SPs because they like them. >>That's honest.

There is no way around it, SP are the 'Hot Setup'.

>>I would happily use SPs if anybody could give me more than an "everybody >>knows" reason.

Not convinced yet? What if I told you I could delete all your data? Using RV's requires permissions on tables. There is nothing stopping a person from creating a connection in, say VB or whatever, an issuing delete statement directly against a table. Using stored procedures, you never assign permissons directly to a table, only to the SP. This way a user will never know the name of a SP to call or what parms to pass to it.

Charlie