Re: Should I Define CASCADE on Database Table or Forms ?

"Brian Dick" <bdick_at_cox.net> wrote in message news:1u4wutruhk5tw$.1fdr8jjxoj1rx.dlg_at_40tude.net...
| On 28 Sep 2004 04:12:47 -0700, xtanto wrote:
|
| > Hi All,
| >
| > We are developing Forms 10g application on Oracle 9i.
| > The question is :
| > For best practice on Master Detail application, should I define
| > cascade on database level or Forms level ?
| >
| > Thank you foryour help,
| > xtanto
|
| Does it make [business] sense to have a Detail row without a Master row?
|
| If yes, then cascade delete is rule specifically for the application and
| should be done by the Form.
|
| If no, then cascade delete is a global rule and should be done by the
| database.
|
| If sometimes, put the cascade delete in a stored procedure and call it
from
| the Form.

this all depends on your cascade rules -- the 'normal' cascade rules should be defined in the database, with constraints where possible. any exceptions should also be defined in the database using specialized stored procedures that can be called by any application

Form's cascade functionality is somewhat legacy, going back to v6 of the database where FK constraints could be declared but had no functionality (IIRC), but they also manage the Form's blocks' resultsets (ie, clear detail blocks as required)

one _major_ disadvantage of Form's cascade functionality, is that it only applies to detail blocks included on the form -- any FK references not maintained via the form will not be cascaded

so, make sure you clearly define your cascade rules, make sure they are implemented in the database, then use the Form's functionality if needed to keep the GUI sync'd

++ mcs Received on Tue Sep 28 2004 - 08:35:53 CDT