This should help...
First, contact your IT department and make sure that the directory containing your Central Library files is Read/Write/Execute for your Library Team only. It should be Read Only for all other users accessing it.
Then, when you install the DxDesigner tools or after you need to update the configuration for the ODBC settings. All users should have the Option setting shown for the .MDB. The Read Only switch should be clicked. This keeps the .LDB or Lock file to remain locked by a user who should not be writing to the MDB database.
Go to you ODBC Setup, and Click Configure for the .MDB file your DxDatabook uses. Select the Options>> and Click on the Read Only box.
I hope this helps you, but I also suggest contacting the Support Desk should you need further assistance.
I also met this kind of problem when I try to update the mdb file but it is read-only because other users linked to the database. But I can not find a MDB setting in the ODBC User DSN tab but we have a mdb setting in the System DSN tab. See picture below.
And in the System Database setting we select None instead of Database. So if I select the Database and it will have to select a mdw file and I don't know where the file is. So can I make no change to the System Database configuratiion (Choose None) and just select Read Only to solve the problem?
We're still having problems with database updates when a user is in DxDesigner, and it's becoming a major PITA, as we are adding more users by the week. One thing I've notices when I go to check a Users ODBC Data Souces setup, some of them have the DxDatabook data source set on the "User DSN" tab, and others have it set on the "System DSN" tab. Does it make any difference which one is used, User or System? What is the preferred one to use per Mentor?
I really would like to be able to apply changes to the database without having to have every user out of DxDesigner. I hope someone can shed some light on this.
I am going to ask our IT folks to double-check the user settings for our library area of the network.
If anyone has some insight, I thank you for taking the time to share it.
I suspect you have alread done the setup as I showed. I typically set this up on the USER tab, but I have seen it on both also and have not noticed a difference. The SYSTEM tab will allow the setup for all users of the machine.
I have inserted text from a .REG file also that you may wish to edit and use in batch install routines to help automate the setup in all users machines.
Windows Registry Editor Version 5.00
"DBQ"="Your Database Path"
One thing I should mention from previously. Your Library should be in a Read Only directory, only writeable to your Librarian/s. Your Access Database file should be placed here also. But here is what I do...
I have a duplicate Library and Database (again only writeable to the Librarian/s), in a separate directory. This is my working Library location. I work here during each day, and have a script to batch update the Central Library location daily each afternoon or evening when no one is in the database. The script is a basic; Backup, Delete, and Copy from the Working Location. This allows the librarian to work unaffected by engineering users during the day. You can fire the script by hand or automate it as you like.
This should help, and should not be a PITA I had 4 librarians supporting 100 engineers accessing the database - we did not have lock issues.
Thanks for your input, and the scripts to automate the Database configuration and updating.
We are doing the same thing you mention, we have a "working" copy of the database that we edit during the day with new information, and a "master" copy in the Central Library. We copy the "working" to the "master" as needed. This does work, but it's not the preferred solution; we would like to be able to edit the "live" database, so the users can see the new parts/properties as they are added. We have been told by many that we SHOULD be able to do this, if all the users are set to read-only. I've double checked and all users are set for read-only in the database config, and I also tested our database location from one of teh users machines, to verify the database folder is set for read-only too. All this has checked out, but there are still times we librarians get locked out of the database (can't edit, move, rename, or copy-over).
I'm a bit confused by your last statement about having 4 librarian, 100 users, and NOT having the lock-out problem; if you didn't have that problem, why are using the Working/Master database scheme?
I guess I was hoping to hear from someone who has actually been successful in having one database file, the LIVE one, and they are still able to edit and manipulate that database when there are users attached. I'm beginning to think it's just not possible for that to be the case.
Again, thanks for all the input, keep it coming if you think of something relevant to share.
P.S. Part of the problem is that some of the engineers leave DxDesigner running ALL the time, when that's the case, we can't even use the Working/Master method, because they lock the "Master" file! We've also seen cases where DxDesigner does NOT release files when you exit.
First you should disconnect all connections to the share .mdb file on the lib server, then copy .mdb file. To disconnect all possible connections to the .mdb file,
you can close the share directory, and share it again after finishing the copy of .mdb file. This is not a bug of Dxdatabook.
Can you please clarify; how do you "Disconnect all the connections to the share .mdb file", and "Close the share directory"?
I have had to physically disconnect a users network cable to release the "hold" the Mentor software had on the database (users workstation was locked, and they were not in the office yet). I haven't found any way to "disconnect" the connections to the database without the "user" doing so, or forcing the issue by pulling their network connection. I'm interested to hear if there are other ways to do it, without having access to the offending users' PC. I also don't know of a way to "Close the share directory".
1 of 1 people found this helpful
In the directory where your database.mdb file is located, you will find a database.ldb file. This is the Lock file.
Open this file in a Text Editor and look at the user names locking your database. Check the System ODBC setups for those users and have them update their setups as explained in this thread and Reboot. I would suggest creating a REG file and having your IT department send it to all users to update thier systems - I expect you have a rogue that is not setup properly, I have had this happen before
Then Delete the database.ldb file. This should release the library database for use.
These settings work, and will work even on the Master library should you not wish to use a working library method. I suggest this method as a way of having a backup, just in case.
The file lock issue is not a DxDatabook or Library issue, but an issue that has plagued Access and ODBC for a long time.
1 of 1 people found this helpful
1 run cmd "openfiles /query"
2 run cmd "openfiles /disconnect "
I have seen the .ldb file before, and I have opened it to see what user has the database locked. It's always been one of the few people that have admin rights to that directory. The thing is, there are times when there is no ldb file there, but I still do not have full access to the database file. I thknk in cases like that, the command lines that Yu provided below may come in handy. I'm going to give those a try the next time I find myself locked out of the database. Thank you to both of you, that deserves a "helpful answer" in my book.
now I am back to corp. and take the snapshot for openfiles operation. From the snapshot, you can see I have easyly deleted the sdd_demo.mdb file on the remote server while a client workstation still connect to the database.
1)on your lib rary server where .mdb resides on, keyin "openfiles /query" or "openfiles". you will see the ids who openning the .mdf file
2)then keyin "openfiles /disconnect /id *"(you can use exact id)。it will reports remote connections be closed.
3)now it's time to copy/move/delete the .mdb file. I deleted it and you see that sdd_demo.mdb now is in the recycle bin
Although this method is valid and fasted way, but I have to point to that this is no't a right way to sync EDA library with other component databases such MRP. In fact, you can implement a more safe and easy way to get your Dxdatabook sysnronrizing with corp's component database.
Which city you live in? it seems you are chinese and from Shanghai. Honywell or Alcatel-Bell?
Thank you so much, Yanfeng. I did not know about these Command Line options for dealing with open files. I think I can make good use of this information.
I realize this thread is a bit old, but I wanted to update this in regard to our situation since we still don't have a viable way to update the database when users are connected. The "OpenFiles" command line stuff looked good, but I talked to our IT people, and it's not something that is currently running on the server, nor will they consider enabling it. Our servers are mostly "virtualized", and they said they would have to turn this on for all "virtual" drives that reside on the physical server machine, and this would cause a major performance hit, so they are not willing to do it. Looks like we are still at the mercy of the users, we have to make sure they exit DxDesigner at the end of the day so we can update the database. Looking for any othe suggestions on this.
From Mentor Tech support.... http:\\supportnet.mentor.com
Please read the following tech note for details:
* Database in a pessimistic locked state
If this not help then please consider the following:
1) Review the .prj file and review if the .dbc file is correct.
2) From DxDataBook, Right Click > Properties and on the Startup tab, see whether this option has a check mark. Connect to databases and update tables at startup. Toggling this option may help if the previously loaded configuration (.dbc) is a problem.
3) In DxDataBook right click > Configure > Edit Configuration and in the libraries tab, check the DSN name for each library. Under each library name in the browser window is a string representing :name>
Notes: MS Access provides a relatively simple locking mechanism whereby users with write/modify permissions to the directory in which the MS Access .mdb file resides can open the database for both viewing and editing by allowing the application to create a lock file (.ldb) in which it tracks users of the database. Without write/modify permissions to the directory in which the MS Access database file resides, the lock file cannot be created.
DxDataBook establishes a connection to the MS Access database on your behalf and uses various queries to read the database. As such, if you don't have read/write permissions to the folder where the MS Access database resides you won't be able to write/modify the MS Access lock (.ldb) file when DxDataBook attempts to read the database. As a result you will be opening the database with an exclusive lock on the table you are accessing since MS Access believes that you've opened the database for the purpose of editing the data. This is referred to as pessimistic locking in MS Access terms. Pessimistic locking means no one else can access this table until the user in it has finished and exited the table.
Make sure that DxDataBook users have "create" and "edit" privileges for the folder where the MS Access database resides. Read-only permission to the actual MS Access database is all that is necessary for DxDataBook users. Librarians and those users who must be able to modify the MS Access database itself must have write/modify permissions on the actual database file in order to make changes to the database.