Subject | Re: [IBO] ERRCODE = 100 & dangling transaction. |
---|---|
Author | Helen Borrie |
Post date | 2003-02-21T13:44:49Z |
At 01:15 PM 21/02/2003 +0000, you wrote:
end of file condition. You can get the values of the SQL errcodes from the
IB Language Reference - there's nothing secret about them.
active.
SessionProps.
commit the transaction it has been using.
monitor, it starts a transaction if it needs to, and holds the transaction
open as long as it needs to. When things go idle, it shuts things down.
Helen
>HelloThe monitor is using it.
>
>Whilst investigating some deadlocks I decided to use the
>TIB_StatusDialog.
>
>After opening and closing one of my forms, a transaction remains
>active.
>
>The form contains one main query and 5 other queries for populating
>TIB_Lookupcombos, all of which use the same IB_Connection and
>IB_Transaction. After further investigation and commenting out code,
>it appears that one of the (lookup) queries is leaving a transaction
>open. This transaction is not the transaction on the form, but my
>main connection's internal transaction.
>The dodgy lookup query is very simple:Not all errcodes are errors - that's just reporting that it has found the
>
> select * from mytable
>
>mytable consists of:
>
> ID int
> mytext varchar(32)
>
>and contains about 6 entries
>
>When watching this executing in the TIB_MonitorDialog, a see a number
>of 'ERRCODE = 100'
end of file condition. You can get the values of the SQL errcodes from the
IB Language Reference - there's nothing secret about them.
>entries (other lookup queries do not get this) andThe monitor will start the transaction for its own purposes, if it isn't
>then there are some statements querying RDB$RELATION_FIELDS,
>RDB$FIELDS tables, which uses a different transaction (the dangling
>active transaction?).
active.
>After closing the form, watching the active transaction in theTime since the transaction was started.
>TIB_StatusDialog shows the 'Time Active' value increasing
>but the State value is inactive !It's not doing anything (from the client's p.o.v.)
>After about 2mins the OAT returns to zero.It times out eventually when inactive, according to the timeout settings in
SessionProps.
>Curiously, the next time I display the dialog, a transaction does NOTThe dialog is just a form made by Jason. It naturally takes good care to
>remain active.
commit the transaction it has been using.
>Throughout this, my form performs as required. Can anyone shed anyIf you commit a transaction, it doesn't "dangle". In the case of the
>light on why this one query should leave a dangling transaction?
monitor, it starts a transaction if it needs to, and holds the transaction
open as long as it needs to. When things go idle, it shuts things down.
Helen