Support Forums - View Thread

View Thread

The following is the text of the current message along with any replies.

Messages 11 to 20 of 21 total

ElevateDB Error #300 Cannot lock object for transaction access

Thu, Apr 3 2008 3:13 PM	Permanent Link
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com	Fons, << The note does say it is also for TEDBQuery, so I still do not quite follow the need to wrap it up inside a transaction. >> That only works for a TEDBQuery that returns a sensitive (live) result set where you're updating the result set directly. It doesn't apply to INSERT, UPDATE, or DELETE statements. -- Tim Young Elevate Software www.elevatesoft.com
Thu, Apr 3 2008 4:15 PM	Permanent Link
"Fons Neelen"	Hi Tim, > That only works for a TEDBQuery that returns a sensitive (live) result set > where you're updating the result set directly. It doesn't apply to > INSERT, UPDATE, or DELETE statements. Just so that I got it right (for my own sake). I use EDB only in C/S mode and I only use INsensitive result sets. Therefore, when executing a single INSERT, UPDATE or DELETE statement, it is totally unnecessary to use a transaction. Correct? Thanks. Best regards, Fons
Thu, Apr 3 2008 4:17 PM	Permanent Link
Michael Fullerton	On Thu, 3 Apr 2008 15:12:48 -0500, "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote: >Michael, > ><< I am using only one session for the whole application. As I understand >it, when a transaction is active no TTimer events should fire untill the >transaction is completed. So when this function is executed there should be >no active transactions. >> > >Timers have nothing to do with transactions at all. So that explains my problem then. If I start a transaction involving TableA. And before it is finished a timer kicks in and runs a SELECT query on TableA I would get the #300 error. But why would a SELECT query need to lock TableA in a transaction? And why is it only the second SELECT query that generates the error? ><< I'm not really doing anything that unusual. >> > >With all due respect, if I had a nickel for every time a customer told me >that.... > ><< Every ExecSQL call in the software is wrapped in a transaction to prevent >data corruption. In the problem function I dynamically create a TEDBQuery. >Running one SELECT is OK but the next one gives this error. Its all the same >query object using the same session. >> > >Could you at least post the code that you're using that starts the >transaction and executes the SQL statements ? The main thing is that you >need to make sure that the SessionName property of the TEDBQuery components >is set to the same as the TEDBDatabase component that you're using to start >the transaction. Well here's an example of the transactions: DM.DB.StartTransaction(VarArrayOf(['TableA'])); try ExecSQL; DM.DB.Commit; except DM.DB.Rollback; raise; end; Here's the function code run from a TTimer: var qry: TEDBQuery; begin Result:= False; qry:= TEDBQuery.Create(nil); qry.DatabaseName:= 'MyDB'; qry.SessionName:= 'My Session'; try with qry do begin //used in timer SQl.Text:= 'SELECT Hours FROM TableB'; Open; if RecordCount < 1 then exit; iHours:= FieldByName('Hours').AsInteger; Close; end; with qry do begin SQl.Text:= 'SELECT SUM(CAST((EndTime-StartTime) MINUTE AS INTEGER)/60) As Hours FROM TableA' +' WHERE PID='+QuotedStr(sP); Open; //#300 error here As I said before, all database objects use the exact same session name.
Fri, Apr 4 2008 2:46 PM	Permanent Link
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com	Fons, << Just so that I got it right (for my own sake). I use EDB only in C/S mode and I only use INsensitive result sets. Therefore, when executing a single INSERT, UPDATE or DELETE statement, it is totally unnecessary to use a transaction. Correct? >> Correct. -- Tim Young Elevate Software www.elevatesoft.com
Fri, Apr 4 2008 2:49 PM	Permanent Link
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com	Michael, << So that explains my problem then. If I start a transaction involving TableA. And before it is finished a timer kicks in and runs a SELECT query on TableA I would get the #300 error. But why would a SELECT query need to lock TableA in a transaction? >> It wouldn't. It would only (possibly) need a read lock, and even that depends upon the situation. That's why I'm thinking that there's more going on here that what we both know. << Well here's an example of the transactions: >> All of that code looks okay. Can you run the application in the IDE debugger and see on what line the error occurs ? That would help immensely in determining the source SQL statement that is causing the issue. -- Tim Young Elevate Software www.elevatesoft.com
Fri, Apr 11 2008 4:46 PM	Permanent Link
Michael Fullerton	On Fri, 4 Apr 2008 14:49:09 -0500, "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote: >Michael, > ><< So that explains my problem then. If I start a transaction involving >TableA. And before it is finished a timer kicks in and runs a SELECT query >on TableA I would get the #300 error. But why would a SELECT query need to >lock TableA in a transaction? >> > >It wouldn't. It would only (possibly) need a read lock, and even that >depends upon the situation. That's why I'm thinking that there's more going >on here that what we both know. > ><< Well here's an example of the transactions: >> > >All of that code looks okay. Can you run the application in the IDE >debugger and see on what line the error occurs ? That would help immensely >in determining the source SQL statement that is causing the issue. Unfortunately I can't. This is all from a customer's MadExcept report. The relevant section of the bug report is below. The line triggereing the report is the second Open statement. ------ 0056f814 MyApp.exe edbconfig TEDBConfigObject.LockError 00523bed MyApp.exe edblockmgr TEDBLockManager.LockObject 00535e49 MyApp.exe edblogmgr TEDBLogManager.BeginUpdate 00535f2f MyApp.exe edblogmgr TEDBLogManager.LogEvent 005cd04d MyApp.exe edblocal TEDBLocalSessionManager.LogEvent 005c6c91 MyApp.exe edblocal TEDBLocalSessionManager.HandleException 005d19e5 MyApp.exe edblocal TEDBLocalCursor.InternalNext 774e1006 ntdll.dll RtlRaiseStatus 774e0e92 ntdll.dll KiUserExceptionDispatcher 00523cd9 MyApp.exe edblockmgr TEDBLockManager.UnlockObject 005aecfc MyApp.exe edblocal TEDBSchemaObjectManager.UnlockObject 005d19ab MyApp.exe edblocal TEDBLocalCursor.InternalNext 005d1e43 MyApp.exe edblocal TEDBLocalCursor.Next 005d4350 MyApp.exe edblocal TEDBCursorValue.GetNextRow 005d4494 MyApp.exe edblocal TEDBCursorValue.NextRow 005d8f87 MyApp.exe edblocal FetchNextRow 005d94b7 MyApp.exe edblocal TEDBQueryManager.ExecuteStatic 005d9cf9 MyApp.exe edblocal TEDBQueryManager.Execute 005dd82f MyApp.exe edblocal TEDBLocalStatementManager.Execute 0060836a MyApp.exe edbcomps 9177 TEDBQuery.GetQueryCursor 006080c4 MyApp.exe edbcomps 9094 TEDBQuery.CreateCursor 00608128 MyApp.exe edbcomps 9108 TEDBQuery.CreateHandle 00602577 MyApp.exe edbcomps 5628 TEDBDataSet.OpenCursor 00604d81 MyApp.exe edbcomps 7294 TEDBDBDataSet.OpenCursor 005f5e4d MyApp.exe DB TDataSet.SetActive 005f5c45 MyApp.exe DB TDataSet.Open
Mon, Apr 14 2008 3:45 PM	Permanent Link
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com	Michael, << Unfortunately I can't. This is all from a customer's MadExcept report. The relevant section of the bug report is below. The line triggereing the report is the second Open statement. >> Wow, something is really screwy at that site. I don't think I've ever seen there be an issue with the log manager being able to update the log file during an exception, which is what is going on. Furthermore, there seems to be an issue with the cursor navigation during the query execution that is starting the whole thing off, and that's another area that is used very frequently. And the customer has no information regarding which area of the application this occurred at ? -- Tim Young Elevate Software www.elevatesoft.com
Tue, Apr 15 2008 12:38 AM	Permanent Link
Dave Harrison	Michael Fullerton wrote: > On Fri, 4 Apr 2008 14:49:09 -0500, "Tim Young [Elevate Software]" > <timyoung@elevatesoft.com> wrote: > > >>Michael, >> >><< So that explains my problem then. If I start a transaction involving >>TableA. And before it is finished a timer kicks in and runs a SELECT query >>on TableA I would get the #300 error. But why would a SELECT query need to >>lock TableA in a transaction? >> >> >>It wouldn't. It would only (possibly) need a read lock, and even that >>depends upon the situation. That's why I'm thinking that there's more going >>on here that what we both know. >> >><< Well here's an example of the transactions: >> >> >>All of that code looks okay. Can you run the application in the IDE >>debugger and see on what line the error occurs ? That would help immensely >>in determining the source SQL statement that is causing the issue. > > > Unfortunately I can't. This is all from a customer's MadExcept report. > The relevant section of the bug report is below. The line triggereing > the report is the second Open statement. Try switching to EurekaLog and it should give you the line numbers of the calling stack. The EurekaLog eval should last 10-14 days before your compiled application times out which should give your client enough time to test it. Dave
Tue, Apr 15 2008 3:15 PM	Permanent Link
"Fons Neelen"	> Try switching to EurekaLog and it should give you the line numbers of > the calling stack. The EurekaLog eval should last 10-14 days before your > compiled application times out which should give your client enough time > to test it. There is nothing wrong with madExcept, but if used the wrong way then it can be dangerous - especially with these kind of tools. BTW, I stopped using EurekaLog and switched to madExcept. And I do not use madExcept the default way, but uses it's routines to trace the stack and this works really well for me. Fons
Fri, Apr 18 2008 6:34 PM	Permanent Link
Michael Fullerton	On Mon, 14 Apr 2008 15:45:04 -0500, "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote: >And the customer has no information regarding which area of the application >this occurred at ? According to the report it looks like it happened on startup. The problem function was called from a TTimer.

« Previous Page	Page 2 of 3	Next Page »
Jump to Page: 1 2 3