Hi Team,
I had recently reported to me an error.."ElevateDB Error #300 Cannot lock the table ChangesLog in the schema Default for transaction access."
Ok.  Fair enough.  Somebody else had the ChangesLog table open.
Seeking to mitigate the consequences I had a look at InTransaction.
Slightly confusing as to its applicability/usability.
In the above example, the Transaction couldn't start due to the other use of ChangesLog.  Would the use of InTransaction test before the StartTransaction have captured/prevented this?
If not, then IIUC, I need to capture the #300 error and process it.

And the answer is??

Regards & TIA,
Ian

On 12/2/2020 10:21 PM, Ian Branch wrote:
> I had recently reported to me an error.."ElevateDB Error #300 Cannot lock the table ChangesLog in the schema Default for transaction access."
> Ok.  Fair enough.  Somebody else had the ChangesLog table open.
> Seeking to mitigate the consequences I had a look at InTransaction.
> Slightly confusing as to its applicability/usability.

It only applies to the current session (yours).

> In the above example, the Transaction couldn't start due to the other use of ChangesLog.  Would the use of InTransaction test before the StartTransaction have captured/prevented this?

No.

inTransaction can be used to check if you (your session) has started a
transaction - in this case you should not call StartTransaction again.


> If not, then IIUC, I need to capture the #300 error and process it.
>
> And the answer is??

StartTransaction will throw an exception of not being able to obtain a
lock and yes so you should handle it and then proceed based on whatever
the logic is.


Raul

Hi Raul,
Tks.

Cheers.
Ian