Hi,

I assume INTRANSACTION checks the table status for all sessions.

Is this true?

Regards,

Mike

Mike


Good assumption. Its not something that's risen to the surface of my mind, but it should be so. If its a concern it should be easy enough to test.

Roy Lambert

Mike,

No, it tests if there is an active transaction on the current session and database (and optionally if a specific table is part of the transaction).
 
--
Fernando Dias
[Team Elevate]

Mike,

Unless you are talking about the TEDBDatabase.InTransaction property that indicates if the database has an active transaction (in the corresponding session).

--
Fernando Dias
[Team Elevate]

Fernando


Reading the manual I'm not sure you're right.

If the current TEDBDatabase component refers to the same database as another TEDBDatabase
component, then calling StartTransaction on one component will also cause the other component's
InTransaction property to return True. This is because ElevateDB never allocates more than one
internal handle for a given database.

If a transaction doesn't encompass all versions of the database (and tables involved in the transaction) then it would mean other users can alter the tables whilst the transaction is in force.


Roy Lambert

Roy,

Are you talking about my first or second post?

--
Fernando Dias
[Team Elevate]

Roy,

I was perhaps not clear, I'm sorry.
Both the INTRANSACTION SQL function and the TEDBDatabase.InTransaction property return True if the *current* session has an active transaction and False otherwise. Transactions started by other sessions are not detected by none of them.

--
Fernando Dias
[Team Elevate]

Fernando


I do hope you're wrong. I don't know, and don't have the source to work it out, but if you are right it would mean that multiple threads using separate sessions (as they're supposed to) can update the database simultaneously, or that the user on PC A can update it at the same time as the user on PC B.

Maybe I'm misunderstanding your use of "session" or maybe I'm just wrong. If I get some time tomorrow I'll do some testing.

Roy Lambert

Roy,

Different sessions can't update the database simultaneously because if a transaction is active EDB will put all the other sessions that try to write on hold until the current transaction ends or until a (long) timeout is reached. That's why transactions have to be kept as short as possible.

--
Fernando Dias
[Team Elevate]

   On 4/28/2019 12:37 PM, Roy Lambert wrote:
> I do hope you're wrong. I don't know, and don't have the source to work it out, but if you are right it would mean that multiple threads using separate sessions (as they're supposed to) can update the database simultaneously, or that the user on PC A can update it at the same time as the user on PC B.
>
> Maybe I'm misunderstanding your use of "session" or maybe I'm just wrong. If I get some time tomorrow I'll do some testing.

AFAIk Fernando is right but i think there is some confusion here.

"InTransaction" tells you if your session has a transaction so you can
use this in code.

Actual data integrity and things like locking associated with
transactions and otherwise is still enforced by EDB for ALL sessions to
the database (yours and others)


You can use "InTransaction" to decide whether you need to start a
transaction or can just run your code that modified data:
i.e.
  if myDB.InTransaction then
  begin
     //start transaction
  end;
  //do actual data changes here as part of transaction either existing
or one you started
  ...


Your code should be ready to be blocked when calling StartTransaction OR
specify timeout and then deal with exception if you cannot start one :

i.e.
if myDB.InTransaction = false then   
begin
    try
      myDB.StartTransaction( EmptyEDBStringsArray,10000);
    except
      on ER:EEDBError do
      begin
        if ER.ErrorCode = 300 then
   // Can't obtain DB transaction locks so deal with this now ....
    ...


Raul