Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 5 of 5 total
Thread ALTER databasename PATH locking
Tue, Apr 20 2010 4:26 AMPermanent Link

Peter

Hello

I'm using D7 + 2.03.9.

When a user is setting up a workstation I write the UNC path to the server to Configuration.Databases.Path. It doesn't matter if it already exists.

If a user has a workstation running my app then the ALTER DATABASE "MyDatabase" PATH %s DESCRIPTION ''%s database UNC path'' SQL fails with a #300 - as the statement requires exclusive access. No probs, but the utility goes into a state of torpor for about 20 seconds while it is trying to get exclusive access, and users do all manner of silly things when there is no feedback.

So I thought to test for exclusive access before the statement above, but the following doesn't throw an exception when a user has the database open, and I thought that it should. Can anyone suggest why this mightn't throw a wobbly?

 EDBTable1.SessionName  :=EDBSession1.SessionName;
 EDBTable1.DatabaseName := 'Configuration';
 EDBTable1.TableName    := 'Databases';
 EDBTable1.Exclusive    := True;
 EDBTable1.ReadOnly     := False;
  try
  EDBTable1.Open;
  except
   on E: Exception do

Regards

Peter
Tue, Apr 20 2010 5:58 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Peter


I can't answer your question but here's a thought - test for the path already being correct before you try and alter it eg

select path from configuration.databases where Name = 'xyz' and Path <> 'unc'

and only alter if its not the same.

From your description I'm guessing that it can only be the same if another workstation has already started the app and in that case the only time you will hit the exclusive problem is when two users try and go on at the same time, a few seconds difference and you're in the clear.

Roy Lambert [Team Elevate]
Tue, Apr 20 2010 7:56 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Peter,

<< So I thought to test for exclusive access before the statement above, but
the following doesn't throw an exception when a user has the database open,
and I thought that it should. Can anyone suggest why this mightn't throw a
wobbly? >>

You're dealing with two different levels of locks.  A table can still be
opened exclusively if everyone has the database opened shared, but a
database cannot be opened exclusively if everyone has the database opened
shared.

--
Tim Young
Elevate Software
www.elevatesoft.com
Tue, Apr 20 2010 8:39 AMPermanent Link

Peter

Tim and Roy

Sorry Tim but Roy's lateral approach won the ribbon, and it works a treat.

But as a matter of interest, how would I go about testing for an exclusive lock on the database?

Regards

Peter
Wed, Apr 21 2010 1:48 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Peter,

<< But as a matter of interest, how would I go about testing for an
exclusive lock on the database? >>

With the ElevateDB Server, you can just query the ServerSessionLocks table:

http://www.elevatesoft.com/manual?action=viewtopic&id=edb2sql&topic=ServerSessionLocks_Table

For local/file-sharing, just try to open the database (TEDBDatabase) and
trap the exception (error code 300):

http://www.elevatesoft.com/manual?action=topics&id=edb2sql&section=appendix_error_msg

--
Tim Young
Elevate Software
www.elevatesoft.com
Image