> > It's a right pain to have to handle this as a special case
> > (using SP's etc to solve).
>
> Maybe this points towards the real problem, that SPs are perceived to be a
> pain? We use Visual Studio to edit and debug stored procedures on a SQL
> Server 7 database and it is very simple, with code highlighting, and
> tooltip-style variable inspection.
>
> I have heard the argument that all updates to a database should be done
> through stored procedures to easily ensure consistency (for a complex
> operation) and enhance security as users no longer need permissions to
> update tables directly.
>
This approach seems to becoming increasingly common and is one which we are
also taking. It works very well for updates and allows you to do very nice
things (such as update stored procs which update multiple tables, create an
audit trail, check the validity of the change, not to mention returning
default/key values as described earlier in this thread). Unfortunately it
doesn't work so well if you want to go to the next logical step and have all
of your data selection via stored procs - it's not really possible to write
good select stored procs which handle multiple possible filter parameters.
David.
DB Solutions.
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
To UnSub, send email to: [EMAIL PROTECTED]
with body of "unsubscribe delphi"
