Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 5 of 5 total |
ALTER databasename PATH locking |
Tue, Apr 20 2010 4:26 AM | Permanent 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 AM | Permanent Link |
Roy Lambert NLH Associates 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 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 AM | Permanent 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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§ion=appendix_error_msg -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Monday, April 29, 2024 at 05:23 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |