Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 6 of 6 total |
Error #300 Cannot lock database X for shared access |
Tue, Mar 10 2009 2:31 PM | Permanent Link |
"Hedley Muscroft" | I'm just in the final stages of testing my newly converted DBISAM4 -> EDB2
application. I decided to test multi-user access.... and I've hit a brick wall! I don't know how, but I completely missed this entire issue as discussed in these old threads :- http://www.elevatesoft.com/newsgrp?action=searchopenmsg&group=16&msg=1765 http://www.elevatesoft.com/newsgrp?action=searchopenmsg&group=16&msg=2325 Basically, it seems that in order to allow network access to database, we can only have ONE EDBConfig.EDBCfg which should be stored on a shared network drive. Unfortunately, my app creates a single EDBConfig file on each computer, but according to the above threads, that's simply not going to work! However, those threads were back in 2007 and seem to relate to EDB v1 - please please PLEASE tell me that EDB v2 has sorted this so that there is some way of using multiple EDBConfig files to access the same shared database?! Thanks, Hedley |
Tue, Mar 10 2009 4:08 PM | Permanent Link |
"Hedley Muscroft" | OK, so further research seems to indicate that the "only use one EDBConfig
file per shared database" is still the case with EDB v2 Typically, my customers use my app either as stand-alone (on 1 machine) or networked on a small LAN (up to 5 PCs). One machine acts as a "pseudo-server" by sharing the database folder using Windows File Sharing and the other computers simply look over the network to access the database simultaneously. Each computer also has its own "Tutorial Database" installed locally for users to work the tutorial which (if I understand correctly) is going to mean multiple EDBConfig files are necessary? --------------- Question 1 --------------- My app needs to have the ability for a user (i.e. any user on the network) to create a new database on their computer and share it with other users on their network. Presumably, I will have to do something like the following (all in code!) :- [1] Allow the user to pick a new directory [2] Create the directory [3] Set a network share on that directory [4] Create an EDBConfig file in that shared directory [5] Create a sub folder called 'data' (for example) [6] Connect to the EDBConfig file and call CREATE DATABASE with a full UNC path : \\computername + '\' + sharename + '\' + data [7] Run my create database script to create the new database in the 'data' subfolder Presuming I do all this, another network user should now be able to access the config file in "\\computername\sharename" and it would all work ok? Of course, if someone removes the share (which can accidentally be done by renaming the shared folder or one of it's parents) then not only are network users screwed (understandable), but so is the local user as they won't be able to access the database as the UNC path in the EDBConfig file will now be invalid?! Are all my above assumptions correct, or is there a better alternative? --------------- Question 2 --------------- Many customers purchase one license of my software (i.e. stand-alone) and then later purchase another license so that they can network it. Now, I could ask users when they first create a database "do you want to share this database on your network" and if they say NO then I could just CREATE DATABASE with a local path. The problem is that if they want to change later, then I have all the added joy of having to share the folder, drop the database, create a new database with the UNC path so that other users can now access it. I'm inclined to make this easier by simply setting up a share on every database folder and using a UNC path even for single user systems. My question is : isn't there an overhead when accessing your own hard disk via a UNC path? In other words, isn't "\\mycomputer\data" going to be slower than "C:\data"? If the answer is 'yes', then surely the EDB necessity that EVERY user must access the database via UNC (even the local computer) diminishes the performance gain that the hosting computer would otherwise get? [As a side point, this is important because my users often install their database on a 'reception desk' computer so that the reception computer (where 90% of the work is done) gets the best possible performance out of the application.] --------------- Question 3 (for Tim) --------------- Is there any possibility at all that something could be done about this? e.g. an override setting so that we can maybe force the EDBConfig lock files to be stored somewhere else (i.e. in a database folder) to get around this? TIA, Hedley |
Tue, Mar 10 2009 5:06 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Hedley,
<< OK, so further research seems to indicate that the "only use one EDBConfig file per shared database" is still the case with EDB v2 >> Yes. However, you have to remember that .Net uses a separate session/database per connection, and each local connection can be pointing to a different configuration file. << Each computer also has its own "Tutorial Database" installed locally for users to work the tutorial which (if I understand correctly) is going to mean multiple EDBConfig files are necessary? >> Yes, you'll need one configuration file on the local machine for the Tutorial with a connection pointing to it, and then you'll need to point the "shared" connection to the shared configuration file on the network resource. << My app needs to have the ability for a user (i.e. any user on the network) to create a new database on their computer and share it with other users on their network. Presumably, I will have to do something like the following (all in code!) :- [1] Allow the user to pick a new directory [2] Create the directory [3] Set a network share on that directory [4] Create an EDBConfig file in that shared directory [5] Create a sub folder called 'data' (for example) [6] Connect to the EDBConfig file and call CREATE DATABASE with a full UNC path : \\computername + '\' + sharename + '\' + data [7] Run my create database script to create the new database in the 'data' subfolder > Presuming I do all this, another network user should now be able to access the config file in "\\computername\sharename" and it would all work ok? >> Yes, that should do the trick. However, have you considered using the ElevateDB Server instead for this ? It would eliminate the requirement of the network share, and you could refer to the "server" machines by their host names from other machines. << Many customers purchase one license of my software (i.e. stand-alone) and then later purchase another license so that they can network it. Now, I could ask users when they first create a database "do you want to share this database on your network" and if they say NO then I could just CREATE DATABASE with a local path. The problem is that if they want to change later, then I have all the added joy of having to share the folder, drop the database, create a new database with the UNC path so that other users can now access it. >> Actually, you don't need to drop the database, just alter it: http://www.elevatesoft.com/edb_faqt_2.htm << I'm inclined to make this easier by simply setting up a share on every database folder and using a UNC path even for single user systems. My question is : isn't there an overhead when accessing your own hard disk via a UNC path? In other words, isn't "\\mycomputer\data" going to be slower than "C:\data"? >> At one point there were some issues with local UNC performance, but I believe that they were resolved in Windows 2000. Of course, this would need to be verified. << Is there any possibility at all that something could be done about this? >> No, that's the design of the system. It's how the license restrictions are enforced, so there's no getting around it. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Mar 11 2009 11:15 AM | Permanent Link |
Dale Derix | Hi Hedley:
> --------------- > Question 2 > --------------- > Many customers purchase one license of my software (i.e. stand-alone) > and then later purchase another license so that they can network it. > > Now, I could ask users when they first create a database "do you want to > share this database on your network" and if they say NO then I could > just CREATE DATABASE with a local path. The problem is that if they want > to change later, then I have all the added joy of having to share the > folder, drop the database, create a new database with the UNC path so > that other users can now access it. How about just using C/S across the board (maybe not for the tutorials). In a C/S situation, the database folder only needs to be visible to the computer that the server is running on. (In a single user situation, both the server and the client applications would be running on the same computer). For single user installations, your client app would hard code Session.RemoteHost to "localhost" (or you could set Session.RemoteAddress to 127.0.0.1. This would force your single user application to only connect to the server on the local machine. If the user later upgrades to a multi-user situation, then all you have to do from any workstation is allow the user to fill in the RemoteHost (or alternately RemoteAddress) properties (and PortAddress) to the computer that the server is running on. There are no sharing requirements for workstations. This also provides added security since none of the workstation computers have access the database files. I must add a disclaimer here that I've only recently started building my first Client/Server database project, so there may be some compelling reasons that I've not thought of for doing the above. (If so, I would love to hear them.) Dale |
Wed, Mar 11 2009 1:44 PM | Permanent Link |
"Hedley Muscroft" | Thanks Tim and Dale for your thoughts / suggestions.
I realize that the EDB Server would probably work better in my scenario. I'm a bit resistant to using it because I already have a 'server' edition of my app which uses PGSQL and I really wanted EDB to offer a zero-configuration 'folder based' solution rather than having to setup and configure an EDB server. I'm currently coding a class which will manage folder sharing, permissions and UNC pathing. Hopefully I can hide it all away under the hood of my app so that users don't have to worry about anything too technical. I've also gone the route of "1 EDBConfig file : 1 database" and I simply create the EDBConfig files in the same folder as the database itself (sorry Tim!). This seems to be the best approach for my scenario and is the closest way of implementing a DBISAM-like folder-database relationship. Besides, all my EDBConfig files are identical apart from the fact that they point to different folders (i.e. their own folder via a UNC path) and they can be easily re-created as needed. IMHO, it does seem that the EDBConfig having to be shared (and therefore the database path references having to be UNC + consistent for every client), is a hugely complicating factor if you're trying to use EDB in file-based mode over a small network. It's certainly orders of magnitude more complex than DBISAM was in the same scenario. That's not to say EDB isn't an excellent product, this just a came as a bit of a shock that's all! Anyway - thanks again for your help guys. |
Wed, Mar 11 2009 5:12 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Hedley,
<< IMHO, it does seem that the EDBConfig having to be shared (and therefore the database path references having to be UNC + consistent for every client), is a hugely complicating factor if you're trying to use EDB in file-based mode over a small network. It's certainly orders of magnitude more complex than DBISAM was in the same scenario. >> Well, for most configurations this is not the case, because there is only one configuration file. What you're doing is certainly not typical at all. -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Tuesday, May 7, 2024 at 06:25 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |