Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 3 of 3 total
Thread OptimizeTable and the table's Active property
Tue, Jul 8 2008 2:46 AMPermanent Link

Pat
Hi all,

I am playing with the OptimizeTable function & cannot figure this out
(dbisam v4)

I have a table on a form and I use a button to run the OptimizeTable
function. In design time, if I leave the table's Active property FALSE
and run my application, then run the OptimizeTable, it runs OK.

Problem is if I set the table's Active property TRUE in design time,
run it, then just before I run the OptimizeTable I do a

 if  MyTable.Active then MyTable.Active:=False ;

the application stops with an #11013 Engine error.

Looks like the code's MyTableActive:=False doesn't make it FALSE
enough for the OptimizeTable. Why?

As a general rule, should I make all table.active properties FALSE in
design mode?

Thank you.

Pat
Tue, Jul 8 2008 3:35 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Pat


Some operations in DBISAM require exclusive access to the table. Optimise is one of them. It essentially rewrites the table in whatever order is specified so you can't have anyone else doing anything to it. In this case, if you're testing the program and have it open in the IDE with the table active DBISAM can't get an exclusive lock on it since the open table in the IDE will prevent it. If you run it outside the IDE and this happens it means there's another copy of your table open in your app somewhere.

I would always have tables closed in the IDE. I use GExperts to make sure that when I compile they are closed. The reason I do this is I found many years ago that Delphi could open tables in the "wrong" order. Think of a master-detail relationship, or lookup fields. You need to open the detail table or the lookup table first.

Roy Lambert [Team Elevate]
Tue, Jul 8 2008 3:56 AMPermanent Link

Pat
Roy,

>Some operations in DBISAM require exclusive access to the table. Optimise is one of them. It essentially rewrites the table in whatever order is specified so you can't have anyone else doing anything to it. In this case, if you're testing the program and have it open in the IDE with the table active DBISAM can't get an exclusive lock on it since the open table in the IDE will prevent it. If you run it outside the IDE and this happens it means there's another copy of your table open in your app somewhere.
>
>I would always have tables closed in the IDE. I use GExperts to make sure that when I compile they are closed. The reason I do this is I found many years ago that Delphi could open tables in the "wrong" order. Think of a master-detail relationship, or lookup fields. You need to open the detail table or the lookup table first.
>
>Roy Lambert [Team Elevate]

thanks Roy Wink
Image