Re
> 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.
I think taking this appoach (updating thru strored procs) is a 'poor mans'
multi-tier
I would either
1/ Put in a middleware layer or
2/ Implement update multiple tables, validity checks et al in triggers
Do you really want to implement a complex middle layer in a script language?
The trigger approach will enforce consistency of update, moving your updates
to
stored procs just splits the logic, doubles the bugs and makes your app less
portable
Regards
Neven
---------------------------------------------------------------------------
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"
