Subject | Re: cascade relations |
---|---|
Author | stanw1950 |
Post date | 2003-08-25T14:08:35Z |
Thanks for the explanations. Actually I missed the fact that he was
using a before insert trigger. Next time I'll follow the whole thread
more closely before asking a question.
Stan
using a before insert trigger. Next time I'll follow the whole thread
more closely before asking a question.
Stan
--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@t...> wrote:
> Stan,
>
> At 04:34 PM 24/08/2003 +0000, you wrote:
> > >
> > > * Make sure an ID is generated for newly inserted Classes and
> > > Class_Dances records. Use GeneratorLinks for both queries
(I've
> > > explained how in an earlier post).
> > > Also make sure you have "before insert" triggers for both
tables
> > > (and probably Dances too) that look like this:
> > >
> > > begin
> > > if ( New.Blah_ID is null )
> > > then New.Blah_ID = gen_id( Blah_Generator, 1 );
> > > end
> > >
> > > ...so the ID that IBO had generated, and inserted, will not be
> > > overwritten!
> > >
> >
> >Paul,
> >If you use GeneratorLinks for your query, why do you need the
before
> >insert trigger?
>
> Consider the Before Insert trigger as enforcing the business rule,
> regardless of the client application that accesses it. Thus, as
long as
> you make your trigger fire the generator ONLY if the new.PrimaryKey
comes
> through as null, the rule works in any conditions. You use server-
based
> rules to serve the database, not a single application. If the
server-based
> rules are broken by an application, then they are wrong rules.
>
> GeneratorLinks (like everything else in drivers and DA components)
is an
> interface feature. The basic aim of the interface is to surface
the API
> (the function calls in the client library) as classes that your
programming
> language can use. All of the available Delphi components (even
DBX, after
> a fashion!) do that. The "extras" surface db features that exploit
aspects
> of engine behaviour. GeneratorLinks is such a one - it takes
advantage of
> the fact that generator values are totally atomic and cannot be
> double-dipped or reversed. It relies on your having expressed the
business
> rule (your "auto-increment trigger") in the recommended,
> application-independent manner.
>
> >How can the id be overwritten when it is only being
> >assigned by the GeneratorLinks in your query? Thanks.
>
> If your trigger simply does
>
> new.PrimaryKey = Gen_ID(TheGenerator, 1)
>
> then it gets fired every time an insert is posted for that table,
> regardless of whether the new row comes through with new.PrimaryKey
null or
> already assigned. So, even though you already have the PK value
you want
> (the one you got via GeneratorLinks), your trigger forces it to
take a new
> value.
>
> In the (very common) case where the application used GeneratorLinks
because
> it needed to know what the new PK would be *before* the row was
posted --
> typically to populate the FK of the detail rows in a master-detail
> structure -- your trigger breaks the relationship.
>
> Helen