RE: Stored Procedures in Client/Server Env.

Jo, > 1) Is there any limit on the number of clients calling a single > procedure at the same time? No. But, there was a bug in earlier versions of OnLine and SE which caused one client to lock the stored procedure so that no others could use is. If memory serves, the bug was #22101 and involved the sysprocplan table. I ~believe~ it is fixed in versions 6.0 an up. Possibly sooner. Try calling tech support if you think you are effected. > 2) How the locking mechanism works for the system tables which have these > stored procedures? Is this a reference to the bug I described above? If not, then I'm not sure how to answer this. Perhaps "onstat -k" can give you some insight (if you're using OnLine). > 3) Can we expect performance improvement using SPs in the large client/server > environment? Maybe. If the stored procedure executes only one or two simple SQL statements, then you won't see any real gain. If, however, the procedure performs a fairly involved sequence, then the fact that procedures are "pre-compiled" will help your performance. Also, if you use the procedure to reduce the amount of info sent over the network, this will help everyone. Stored procedures are a very powerful tool in a client/server environment. It helps to reduce some of the "fat client" problems everyone runs into. Also, keep in mind the ease of stored procedures. They help encourage code reuse and can be changed w/o recompiling and redistributing client code. Don't just look for the performance gains! Thanks for asking the questions. (<- Wow, you guys are right. I, too, like the kinder, gentler netiquette. Thanks for suggesting it. :) --Craig (craig@chemistry.utah.edu)