Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 10 of 22 total |
INTRANSACTION |
Sat, Apr 27 2019 7:21 AM | Permanent Link |
Mike | Hi,
I assume INTRANSACTION checks the table status for all sessions. Is this true? Regards, Mike |
Sat, Apr 27 2019 7:34 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Sat, Apr 27 2019 11:08 AM | Permanent Link |
Fernando Dias Team Elevate | 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] |
Sat, Apr 27 2019 11:12 AM | Permanent Link |
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] |
Sun, Apr 28 2019 8:31 AM | Permanent Link |
Roy Lambert NLH Associates 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 |
Sun, Apr 28 2019 9:12 AM | Permanent Link |
Fernando Dias Team Elevate | Roy,
Are you talking about my first or second post? -- Fernando Dias [Team Elevate] |
Sun, Apr 28 2019 9:35 AM | Permanent Link |
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] |
Sun, Apr 28 2019 12:37 PM | Permanent Link |
Roy Lambert NLH Associates 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 |
Sun, Apr 28 2019 5:33 PM | Permanent Link |
Fernando Dias Team Elevate | 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] |
Sun, Apr 28 2019 9:10 PM | Permanent Link |
Raul 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 |
Page 1 of 3 | Next Page » | |
Jump to Page: 1 2 3 |
This web page was last updated on Tuesday, May 14, 2024 at 07:14 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |