Ed Leafe wrote: > On Nov 15, 2007, at 6:28 PM, Uwe Grauer wrote: > >>> May I ask why you can't configure your database to use the >>> referential integrity constraints that would match the behavior you >>> want? From the ibphoenix site: >> BTW, the main site for firebird is firebirdsql.org >> The FAQ is on firebirdfaq.org > > Fine, but you didn't answer the question. > >> The app logic can explicitly override the integrity constraints of the >> database if it knows about how to do so. > > This is so wrong on so many levels. Database constraints enforce > data integrity, period. An application should never be able to act in > a way that is contrary to data integrity. >
That's what the database does (forcing data integrity). But in my application layer, if the user wants to delete a person, the logic should delete the address childs of the person prior to the deletion of the person record. By specifying REFINTEG_CASCADE the developer tells the bizobj that he wants to have the addresses deleted in order to be able to delete the person. This doesn't work just because the dabo implementation does it in the wrong way. So the way it is coded, Dabo unnecessarily forces the developer to code it for himself. There are always two point of views. From the database (force integrity) and from the app layer (cascade the deletes in a way which allows integrity). > If deleting a record should result in any related child records > being deleted, then the database should be configured to that design. > If the database is configured to expressly prohibit deleting a record > with associated child records, then it follows that your app will > have to respect the database design and only allow deletion of > records with no related children. > I explain it again: The database sees "delete from person where pk = xxx". If there are childs, it has to force integrity. The app logic of the person form gets the user click "delete this person". In order to do so, according to the integrity rules the developer specified the CASCADE rule. So from the apps point of view, this means to delete the address childs prior to be able to delete the person record. I can't see why the CASCADE should be allowed to do the deletes in the wrong order. Is REFINTEG_CASCADE only there to not be forced to do a requery on the child table in the special case when the database does a ON DELETE CASCADE? That would be odd. > There is an expression in English: having your cake and eating it, > too. Is there anything equivalent in German? > Don't know. You are right, my proposed logic is a bit questionable. My point of view is the applications point of view. Maybe we can invent something like REFINTEG_INVERTED_CASCADE? Uwe _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/dabo-users/[EMAIL PROTECTED]
