Subject | Re: possible trigger problem under 1.5.4.4910 |
---|---|
Author | sjlukacs |
Post date | 2007-10-18T19:34:22Z |
ok, i know that this one is hanging out there a while, but i have had
a hard time reproducing this bug. at this point, i am not sure if it
is my delphi 7.1 with interbase express 7.08 application or firebird
itself. so perhaps i can explain the problem as best as i can and we
can explore the possibilities together.
as stated in a previous post, a detail table is updating a value in
the master table. the field happens to be an accrual or summation
floating-point field. if i insert a new record in the detail table,
its triggers will automatically update the accrual value in the field
of the master table. using the VARS table, i have been able to find
out that when the detail table has a new insert, it is posted, and
then hard-committed, then say an unrelated field is changed and posted
in the master table, everything works fine. the times that the
accrual field is not properly updated is when the hard-commit is not
performed before changing the unrelated field in the master table. if
i simply post the insert in the detail table, then immediately change
the unrelated field in the master, then the accrual field is not
updated appropriately. upon inspection of the VARS table, which
receives messages from the triggers, it is apparent that the triggers
are firing just fine. however, the when the hard-commit is not
performed the NEW value in the master table reverts to the previous
instead of the current value. i hope i didn't explain that in a
confusing way. just guessing, but perhaps in the detail trigger
reading the current value from the master table using a SELECT is
reading only the committed values instead of the value in the current
transaction. it is only by doing the hard-commit prior to changing
the unrelated field in the master will the proper value be read
because the hard-commit causes it to read the value off the hard-drive.
ok, that said, i hope that made sense and can anyone offer any
suggestions. perhaps i need to change some settings in the trigger
configuration.
thank you in advance.
lucas
a hard time reproducing this bug. at this point, i am not sure if it
is my delphi 7.1 with interbase express 7.08 application or firebird
itself. so perhaps i can explain the problem as best as i can and we
can explore the possibilities together.
as stated in a previous post, a detail table is updating a value in
the master table. the field happens to be an accrual or summation
floating-point field. if i insert a new record in the detail table,
its triggers will automatically update the accrual value in the field
of the master table. using the VARS table, i have been able to find
out that when the detail table has a new insert, it is posted, and
then hard-committed, then say an unrelated field is changed and posted
in the master table, everything works fine. the times that the
accrual field is not properly updated is when the hard-commit is not
performed before changing the unrelated field in the master table. if
i simply post the insert in the detail table, then immediately change
the unrelated field in the master, then the accrual field is not
updated appropriately. upon inspection of the VARS table, which
receives messages from the triggers, it is apparent that the triggers
are firing just fine. however, the when the hard-commit is not
performed the NEW value in the master table reverts to the previous
instead of the current value. i hope i didn't explain that in a
confusing way. just guessing, but perhaps in the detail trigger
reading the current value from the master table using a SELECT is
reading only the committed values instead of the value in the current
transaction. it is only by doing the hard-commit prior to changing
the unrelated field in the master will the proper value be read
because the hard-commit causes it to read the value off the hard-drive.
ok, that said, i hope that made sense and can anyone offer any
suggestions. perhaps i need to change some settings in the trigger
configuration.
thank you in advance.
lucas