johan_bosaeus wrote:

>
> After a little more research, we found out that setting the
> isc_dpb_dbkey_scope option to 1 in the isc_attach_database call, was
> the culprit.

Correct, as it forces the engine to start a dummy snapshot transaction.

> The documentation states that if you want the "dbkey" to
> be session-wide, set it to 1? We are running several threads against a
> database connection, so that sounds right?? Does the database handle
> concurrent access to a single database handle, although this options
> is set to 0?

This option has [almost] nothing to do with concurrency. It's about
consistency of query results if your code shares the retrieved DBKEYs
(and probably BLOB IDs as well) among transactions, in particular uses
them in transactions other than the ones they were retrieved in and
after they were committed (or rolled back).

This is not a recommended practice, so supposedly you don't need this
option.


Dmitry