Subject | Re: [firebird-support] Making View Updateable - Newbie |
---|---|
Author | Helen Borrie |
Post date | 2004-12-13T04:04:44Z |
At 01:29 AM 13/12/2004 +0000, you wrote:
do an update that causes the record not to "fit" the view description any
longer, then a refresh of the view won't show the record. This doesn't
accord exactly with what you are describing, since an updated record is
visible to the transaction that it is within, regardless of transaction
isolation.
If the boot is on the other foot, and it is a select on the table that
seems to be telling you lies, then commit the transaction that's showing
you the table and look again. (Note that, even if the select * from atable
transaction is in READ COMMITTED isolation, you'd still need a Refresh of
the dataset to actually see the change...)
Further than that, couldn't make a guess without looking at both the table
and the view definitions.
cheers,
./heLen
>I'm using FB 1.5.1 with XP Home SP2 and IBExpert.Just make sure that you are looking at the latest view of the data. If you
>
>I have two tables linked in a 1:1 relationship; the detail table
>uses it's Primary Key as a Foreign Key to the master table. (BTW -
>should I even have a Primary Key on the detail since it appears that
>FB generates two Indexes for the same field when the detail table is
>created?)
>
>I have constructed a view with both these tables - using Helen's
>excellent FB book I've been able to write an insert trigger to
>insert a new row into both the base tables.
>
>My problem arises when I want to update the base tables through the
>view. My before update trigger allows (for example) a field value
>to be entered into the IBExpert data grid and accepts the value when
>I press the post key - however, when I perform a commit the field
>reverts back to it's original/old value - with no error message or
>any other indication of a problem.
do an update that causes the record not to "fit" the view description any
longer, then a refresh of the view won't show the record. This doesn't
accord exactly with what you are describing, since an updated record is
visible to the transaction that it is within, regardless of transaction
isolation.
If the boot is on the other foot, and it is a select on the table that
seems to be telling you lies, then commit the transaction that's showing
you the table and look again. (Note that, even if the select * from atable
transaction is in READ COMMITTED isolation, you'd still need a Refresh of
the dataset to actually see the change...)
Further than that, couldn't make a guess without looking at both the table
and the view definitions.
cheers,
./heLen