Subject | Re: [ib-support] How trigger changes can become visible in current Delphi transaction |
---|---|
Author | Helen Borrie |
Post date | 2002-11-08T09:21Z |
At 08:41 AM 08-11-02 +0000, you wrote:
generated key would be? It is very simple: you get the generated value
*before* the transaction is posted. You can write a very simple function
in Delphi to do this.
You need to change your triggers to the following:
create trigger bi_atable for atable
active before insert position 0
as
begin
if (new.thePriKey is null) then
new.thePriKey = gen_id (gen_atable, 1);
end
This way, the generator will fire only if your application does not pass
the new generator value to it.
IBObjects actually provides a client-side Gen_ID function and even a
property (GeneratorLinks) so that you never have to worry about your
generator values. I expect that FIBPlus also does similar.
Trigger changes do actually take effect when posted, however; and you can
use CommitRetaining to keep your datasets open. The "new" transaction that
is started after a CommitRetaining retains the cursor from the previous
transaction so, with effective data access components that can do clever
things to refresh your output set, starting the new transaction won't
interfere with your user interface...
This isn't a Delphi list, by the way. Each of the specialised Firebird
components has its own list - you can pick up the subscription addresses
from the Lists and Newsgroups page at the firebirdsql.org website.
heLen
>All changes performed by triggers are not visible to my current DelphiNo. I assume you are wondering how to have your application "know" what a
>transaction until it is not committed. Is it possible to made these
>changes visible without restarting current Delphi transaction?
generated key would be? It is very simple: you get the generated value
*before* the transaction is posted. You can write a very simple function
in Delphi to do this.
You need to change your triggers to the following:
create trigger bi_atable for atable
active before insert position 0
as
begin
if (new.thePriKey is null) then
new.thePriKey = gen_id (gen_atable, 1);
end
This way, the generator will fire only if your application does not pass
the new generator value to it.
IBObjects actually provides a client-side Gen_ID function and even a
property (GeneratorLinks) so that you never have to worry about your
generator values. I expect that FIBPlus also does similar.
Trigger changes do actually take effect when posted, however; and you can
use CommitRetaining to keep your datasets open. The "new" transaction that
is started after a CommitRetaining retains the cursor from the previous
transaction so, with effective data access components that can do clever
things to refresh your output set, starting the new transaction won't
interfere with your user interface...
This isn't a Delphi list, by the way. Each of the specialised Firebird
components has its own list - you can pick up the subscription addresses
from the Lists and Newsgroups page at the firebirdsql.org website.
heLen