I have an access database that is on a network drive that multiple users can access. The database corrupted this morning and I am in the process of trying to fix it. The problem I am having is when I attempt to rename the database it says it is currently in use by someone. There is no .ldb file associated with this file so at this point and am dead in the water because I can't rename it, compact it or anything.
Does anyone have any suggestions?
Thanks
Copy the database to another location. The copy wont be locked. Then you can work in ways to save your work until you solve the lock problem in the original file. If your problem is due to VB code file corruption, try to open the database with the "/decompile" option:
Start-Run:
"C:\Program Files\Microsoft Office\Office\msaccess.exe" "C:\example.mdb" /decompile
If you haven't any ldb file associated with the mdb, it will be difficult to discover what user is locking your database. If you have few users, you should restart their machines. It would be prehistoric but should be fastest than trying to unlock the file through other ways.
Just had to do this, Try "F11" then select "tables", select topic and click open, from there it a simple C&P into excel sheet.
Hope this helps
Dave Pragnell
ldb file is automatically created when first user opens the DB, it tracks the number of users who have opened the DB and locking status of every object
so if one user is open in read only then 2nd user can edit db
this file automatically deleted when last user close connection to the db file.
You dont manually delete/modify this file, as it may result into inconsistent state of DB
You can open this file in Notepad and check how many users have opened this file, But DONT change anything.
Related
I have copied database folder from wamp/bin/mysql/data
As I open the phpMyAdmin, I see the database name, but when I click on them it is empty, as if no table has been created in them.
Where are my tables now? thanks
Copying the MySQL data directory is not a reliable means of backing up or moving your databases. The supported means is to export then import on the new server. There are a number of things that can go wrong, especially if you have InnoDB type tables.
The basic things you can check are file permissions on the new data directory, MySQL-level user permissions (assuming you're not already logged in as an administrative user, try doing so and see if things improve), and looking in the MySQL error log for any hints if there's something obvious, but it's very likely that something didn't transfer well.
I recommend that you go back to the original installation, verify your data, do a complete export (or "dump") to SQL format, then import that file to your new server.
The company is using an old Delphi software, that uses a .mdb file as database.
I can't change the way the application works, I don't have it's source.
We are facing many problems such as:
Lock problems
When an user adds an entry, it doesn't update the database, it only appears locally
The lock problems are solved for now, currently, the problem is that only the first user that connects to the .mdb can edit, add and delete entries, the other users do that to, but the changes are not applied to the db, it seems it's only apply locally, on the user machine.
My question is, is .mdb supposed to work with many users over the network(3~4 people)?
What Is there anything I can do to make this software works well with the .mdb file, with many users?
Remembering that I cannot split the .mdb, as I cannot edit the Delphi application.
You don’t mention that if this in the past work fine in a multi-user environment. However, keep in mind that users MUST have full read/write AND ALSO file create and delete rights.
The reason for the create and delete rights is that because this is a “file based” system without a server process, then a locking file is created in the same directory as the back end mdb file. When the first user opens the file, and they don’t have FULL RIGHTS to the folder, then the file is opened in exclusive mode, and all additional users will be read only. This thus explains your symptom of first user in, but additional users don’t work. (the additional users will be read only – and obviously the Delphi software does not detect this problem). So you can view data – but no saving of data can occur.
So you need to ensure that all users have the ability to create that locking file. It is created by the first user, and any additional user opening the back end ALSO needs rights to that file (so don’t by mistake have permissions to the folder set on a per user basic, since then the first user in will cause JET to create the locking file but with permissions to that first user!. Once again this will mean additional users will be read only. So additional user MUST be able to open the locking file, and the first user in MUST be able to create the locking file. In fact open Access will open the database (mdb) as exclusive and prevent multi-user when the locking file cannot be created.
When the last user leaves the database (or in your case leaves the Delphi application), then the back end file is closed and ALSO THE locking file is deleted by the database engine (JET)
So this sounds like your IT folks did not give wide open permissions to the back end folder. You “can” run the database with file delete rights removed, but I much suggest that the locking file being re-cycled is also a good thing since over time it can become damaged etc.
So based on your symptoms, this is a VERY common occurrence in Access, and this problem is fixed by giving all users sufficient permissions to create files in the same folder as the back end. (and not permissions based on per user).
ALL users must be able to create + open + use that locking file created by the first user opening the mdb file. This locking file creation is automatic and managed by the JET database and not the Delphi program.
Yes, it can work with x ppl on a network.
Make sure the Access database is set to open in shared mode, which is the default setting.
Tools menu, click Options.
On the Advanced tab, under Default open mode, click Shared.
Use this Powershell script:
Get-SmbOpenFile | Where-Object -Property ShareRelativePath -Match ".mdb" | Close-SmbOpenFile –Force
Ive got an mde file and all i need is to get data from tables of this file in any format... I've tried everything that I could find on the internet or get by myself, but nothing helps. When I am using standard tools for extracting data in access it says to me, that I have something running operations on that database( I think there is some kind of a macro or something else, that starts when I open this file).
If you have any info on how to get data from this file I will be SO thankfull!
Thaks again for your attention and I really sorry for my bad english(doing my best to learn speaking it better).
There are a few tricks you can try:
Press SHIFT when opening the file to disable autoExec macros.
Just in case the file is corrupted, try to compact and repair it (make a backup copy before!).
You can use the command line option /compact to perform the compact and repair without first opening the file.
You can create a new database and create linked tables from the other database.
You'll have the option of copying the whole tables (you may need to rename the .mde into .mdb so you can see it in the dialog asking for the file to link to).
I have an Access file on a server which my colleagues will update regularly and sometimes I need to analyze the data by the following method:
download the Access file to my local drive
export the table to MySQL
open the MySQL table through R to do the analysis
This workflow is OK if I only have to do it once, but it's getting more often that I find data is missing inside the dataset, I asked the colleagues to fix it, and then I need to go over step 1-3 again, and I feel it is kinda dumb to do the 1-3 steps over and over again.
Since the Access file on server is password protected and I don't want the mess with that file, I wonder if I can created another Access file, that acts as a link between my local MySQL server and that Access file. When I launch R, data will be extracted from the MySQL server, go to my "link" Access file, and go to the Access file on server, and everytime the data I get from R is the latest version.
I wonder if I have explained it clear enough, and I have no clue how to work this out, can anyone here inspire me? Thanks!
Try:
> install.packages("RODBC")
> vignette("RODBC")
I'm working on a MS Access database. I've made some changes to one of the modules. I want to go out for lunch, but when I try closing the database, I get the following message:
"You do not have exclusive access to the database. Your design changes cannot be saved at this time. Do you want to close without saving your changes?"
I'm pretty sure nobody else on the network has the database file open, and I don't have any other Access databases open. I'm probably missing something obvious, but would really appreciated some help!
Update:
In the end I copied all the code, closed the database without saving, re-opened it and pasted the code back in. I was then able to save the database. I'm not sure if this was a one off, but I'll report back if it happens again.
If you're sure no one else is in the db but you, it's an additional connection to your db from your own pc. You can verify this with the LDB viewer, downloadable in the free JetUtils.exe download from Microsoft:
http://support.microsoft.com/kb/176670
Look through your code and check if you have two separate database objects in the default workspace or another database object in a separate workspace. That will cause this problem.
To fix it, make sure the database objects are set to nothing before they go out of scope, and if you opened the database object in code, you also need to close it before setting the database object to nothing.
=============================================
Update in August 2022:
The MS link above no longer works. The document remains available on Archive.org, but is outdated. A document that appears to provide the current version of its information is at:
https://learn.microsoft.com/en-us/office/troubleshoot/access/determine-who-is-logged-on-to-database
This provides VBA code for a sub to obtain a list of users. The writer of this update has tested that code successfully in Access 2019.
If you close the database and are sure nobody else has it opened, check to see if there is a .ldb file (it will have the same name as your database file). If the file is there, then there is a good chance it is still in use.
Is it being access by a service, like a website?
You could copy the database to another sub-directory and make your changes. If that doesn't work, I will have to look that up. Of course there is always the database tool, "repair and compress database..."
Is the file located on a file server? If so check to see if any users have a file handle to it.
If it still doesn't work, update your post with your new information and we'll go further.
UPDATE (9/26):
Another thing I do when having strange issues with access databases with contain vba code is decompile. I don't know if this is documented yet, I haven't looked in years, but it's was (at least) an undocumented switch to msaccess.
From a cmd line:
change directory to where msaccess.exe is located.
Run the following command
msaccess \path to access file\databasefile.mdb /decompile
usually runs very quick then opens the database. Open any module and compile.
Doesn't always work, but sometimes can remove strange happenings.
Did you ever trying to copy the database to another directory and making your edits? That should of worked; you could then rename the original and copy the file back.
Anyway, I am glad you are working again.
If even a word mail merge is linked to the access database, that counts as an access connection.
Very simple.
Close all of your MSaccess files.
Open task manager (by right click on task bar).
Select Processes tab in that.
If the list has a msaccess*32 process close that by clicking on End Process.
This worked for me. I think it closes all the recordset which we have not closed in the codes or which is closed forcefully.