Though I don't know exactly what your sprocs are doing, the number of sprocs has very little to do with the drag it will create on your application. Having 6 sprocs triggered by some database operation is nothing compared to some of the SQL Server databases I've seen. Your boss is most likely correct that the processing is faster via sprocs, especially if they are data intensive and even more so if the database is accessed over a WAN. Whether or not the design is correct or it could be done more efficiently by shifting the processing to the client is really impossible to tell without all the information available, but tests could certainly be run to determine whether this is presenting a bottleneck as it appears the design has already be implemented. Actual tests versus conjecture are usually a far better indicator whether there is problem when you've reached the stage of development you have. That's my two cents anyways.

>This is more of an opinion question. I'm currently working on a new Sales Order Entry using VFP9. I've gotten to a point where each item I add to an order has to go through a series of validations...tax, discounts,in stock,and so on. My boss decided that each module should be written as a stored procedure. I wasnt to sure on the idea, I wasnt thrilled about coding this in T-SQL but I've gotten through it. Now I dont see much of a speed problem with them individually but when all 6 are tied together it kinda worries me. Do you think this is a good idea, or should they have been done as maybe com objects or methods.
>
>There is a lot of data involed with each stored procedure and my boss's arguement is that its cloer to the data adn thus faster. I just didnt think 6 stored procedures in a row was such a good idea.....
>
>Opinions appreciated!!!TIA!!!