Two reasons. One was that Cognos had their own "optimistic concurrency
control" which unstable dbkeys yanked out the rug beneath. The other is
that "consistency mode" murders concurrency, which is why they developed
the optimistic concurrency control for other database systems in the
first pl
> -Original Message-
> From: Jim Starkey
> Sent: May 19, 2022 3:08 PM
> They have nothing to do with each other. A transaction isc_tpd_consistency
> keeps two phase table locks to make transactions serializable. An
> attachment with isc_dpb_dbkey_scope is about preserving dbkeys acros
They have nothing to do with each other. A transaction
isc_tpd_consistency keeps two phase table locks to make transactions
serializable. An attachment with isc_dpb_dbkey_scope is about
preserving dbkeys across transactions within an attachment.
On 5/19/2022 2:35 PM, Leyne, Sean wrote:
--
> -Original Message-
> From: Paul Beach
> Sent: May 19, 2022 12:10 PM
> It maintains all the rdb$db_key values for the length of a connection - i.e.
> they are not allowed to change. An internal transaction gets started for this.
> It was introduced to support Cognos' Powerhouse 4GL pr
>How is subj supposed to work? I see that it forces engine to start a
> transaction and that's all.
It maintains all the rdb$db_key values for the length of a connection - i.e.
they are not allowed to change. An internal transaction gets started for this.
It was introduced to support Cognos'
If I remember correctly, it starts a transaction to inhibit garbage
collection for the duration of the attachment so any dbkeys returned
remain valid across succeeding transactions on the attachment.
On 5/19/2022 11:38 AM, Dimitry Sibiryakov wrote:
Hello All.
How is subj supposed to work? I
Hello All.
How is subj supposed to work? I see that it forces engine to start a
transaction and that's all.
--
WBR, SD.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
