Support Forums - View Thread

View Thread

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

Messages 1 to 10 of 21 total

ElevateDB Error #300 Cannot lock object for transaction access

Wed, Apr 2 2008 12:19 PM	Permanent Link
Michael Fullerton	I get this error: ElevateDB Error #300 Cannot lock object for transaction access using a dynamically created TEDBQuery. I use it for a simple select query and its OK. Close it, change the SQL and get the error on open. What would be wrong here?
Wed, Apr 2 2008 2:18 PM	Permanent Link
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com	Michael, <<I get this error: ElevateDB Error #300 Cannot lock object for transaction access using a dynamically created TEDBQuery. I use it for a simple select query and its OK. Close it, change the SQL and get the error on open. What would be wrong here? >> What is the SQL statement that you're trying to execute ? Are you using transactions elsewhere in your application ? -- Tim Young Elevate Software www.elevatesoft.com
Wed, Apr 2 2008 2:32 PM	Permanent Link
Michael Fullerton	On Wed, 2 Apr 2008 14:18:53 -0500, "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote: >Michael, > ><<I get this error: > ElevateDB Error #300 Cannot lock object for transaction access > > using a dynamically created TEDBQuery. I use it for a simple select query >and its OK. Close it, change the SQL and get the error on open. What would >be wrong here? >> > >What is the SQL statement that you're trying to execute ? Are you using >transactions elsewhere in your application ? The SQL statements are both simple SELECTs. The function though is called from a TTimer. I use transactions around every ExecSQL call in the software.
Wed, Apr 2 2008 3:37 PM	Permanent Link
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com	Michael, << The SQL statements are both simple SELECTs. The function though is called from a TTimer. I use transactions around every ExecSQL call in the software. >> So are you trying to execute an SQL statement using a different session against a database that already has an active transaction from another session ? Perhaps you could send me an example of what you're doing ? -- Tim Young Elevate Software www.elevatesoft.com
Wed, Apr 2 2008 4:03 PM	Permanent Link
Michael Fullerton	On Wed, 2 Apr 2008 15:37:16 -0500, "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote: >Michael, > ><< The SQL statements are both simple SELECTs. The function though is called >from a TTimer. I use transactions around every ExecSQL call in the software. > >> > >So are you trying to execute an SQL statement using a different session >against a database that already has an active transaction from another >session ? 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. >Perhaps you could send me an example of what you're doing ? I'm not really doing anything that unusual. 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.
Wed, Apr 2 2008 4:26 PM	Permanent Link
"Jeff Cook"	Hi As a mere DBISAM v3.30 user I'll dare to comment ... Michael Fullerton wrote: > > 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. > Is this true ... "no TTimer events should fire until the transaction is complete" ... ? Why would that be? -- Jeff Cook Aspect Systems Ltd www.aspect.co.nz + Joan and Jeff Cook The Cooks Oasis www.cookislandsoasis.com
Wed, Apr 2 2008 4:58 PM	Permanent Link
"Fons Neelen"	> I'm not really doing anything that unusual. 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. A single SQL execution of, for example, a single UPDATE instruction does not need to be in a transaction. Either it executes without problems of it does not - and if not, no need to rollback anything. Only if you are executing multiple SQL instructions that have a "kind of relationship" than it is wise to wrap it up inside a transaction. Fons
Wed, Apr 2 2008 7:16 PM	Permanent Link
Michael Fullerton	On Wed, 2 Apr 2008 22:51:02 +0200, "Fons Neelen" <fons.neelen@xs4all.nl> wrote: >> I'm not really doing anything that unusual. 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. > >A single SQL execution of, for example, a single UPDATE instruction does not >need to be in a transaction. Either it executes without problems of it does >not - and if not, no need to rollback anything. You need to put it in a transaction if you want cached updates to be written out immediately so you can prevent table corruption. There is no FlushBuffers call for TEDBQuery.
Thu, Apr 3 2008 2:45 PM	Permanent Link
"Fons Neelen"	> You need to put it in a transaction if you want cached updates to be > written out immediately so you can prevent table corruption. There is > no FlushBuffers call for TEDBQuery. This is from the EDB manual: --------------------------------------- procedure FlushBuffers Usage Use the FlushBuffers method to flush data to disk. If the table, view, or query result set being updated is opened exclusively, then the FlushBuffers method flushes all cached writes in ElevateDB to disk and proceeds to instruct the operating system to flush all cached writes to disk also. If the table, view, or query result set is opened shared, then FlushBuffers only instructs the operating system to flush all cached writes to disk since shared datasets in ElevateDB do not cache any writes. Note This method is only used in the context of the descendant TEDBTable, TEDBQuery, and TEDBStoredProc components. --------------------------------------- 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. Fons
Thu, Apr 3 2008 3:12 PM	Permanent Link
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com	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. << 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. -- Tim Young Elevate Software www.elevatesoft.com

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