I'm a great fan of stored procedures, and IMO, no application should ever touch a table directly. Not even with a select. Stored procedures should act as an extra abstraction level. Besides from the reasons given by other people, it gives database people the opportunity to re-organize the data layout (add/delete columns, split tables) without having to modify an unknown number of programs - all that's needed is to change the relevant stored procedures. Granted, probably less important for a database that's the backend for a short-lived website, but very important for databases that will last for decades, with a myriad of applications running against it. If there's any intention your database is going to last for a while, in an environment that might change don't use any SQL code in your applications (except for calling stored procedures). Ever.
If your DBA doesn't give you permission, you have a problem. But not a problem different than your sysadmin not giving you permission to write files either. Would you accept the latter, and search for a way to get programs on the system (perhaps by typing them in on the command line each time you want to run them)? Or would you make it so that you get access? Assuming your application is important for someone, go and get the access you need! Talk to your manager.
In reply to Re^2: No stored procedure bashing on my watch!
by Anonymous Monk
in thread Recoding a multi-sql-statement storedProc transaction in a script
by punkish
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |