I have compact on close enabled but databases in my local GDrive folder do not complete the compact/repair operation (Office 365 64 bit).
The message is:
The compact and repair operation has been cancelled. You might not have adequate permissions to the folder that the database is located in. You need full permissions to the directory the database is located to compact and repair. Contact your system administrator for more information.
I notice that when this is displayed, Access has created a temporary database for the operation: Database.mdb.
When I look at the properties of this file, there is a security message:
This file came from another computer and could be blocked to protect this computer.
There is the usual "Unblock" checkbox.
I have this folder and subfolders added to the trust centre settings, but can't work out why this is happening. On my other PC, accessing the same files synchronised using the google drive app, I don't have the same problem.
The file is only ever opened by one person in one location at a time. It doesn't seem to be an ownership or machine-specific problem. If I create a new database in this folder, and enable compact on close, I get the same result.
I can copy the file(s) to another folder and compact/repair works fine. So, it's not a huge deal, but I'd like to know what's going on.
All help much appreciated.
Related
Recently, my Xubuntu distro crashed. I wasn't trying to retrieve it. Rather get all the information that are required. I was trying to find database folders I ended up with getting some files whose extensions are frm ibd and opt in the following location : /opt/lampp/var/myqsl/database_name.
With a quick search, I have came up with "solution" (who knows if that actually works). That is, I have to copy the database folder and paste it to the exact same location (In another system, that's what I am planning). But I didn't see a solution like that in SO so, I am highly in doubt. And by installing a new distro, I won't have access to those files anymore.
FYI, I don't have access to anything rather than just files that exist in Xubuntu.
I have just finished completing a robocopy move of data from one network share to another (new) share.
It appears all the MS Access databases are now prompting for a password when they haven't had one set. I have done extensive searches and haven't yet been able to find a solution.
I thought it may have been a security permission issue on the new share however I have copied the file to my local drive and I get the same password prompt. All users have full access to open this file.
I don't know anything about Access and even less about databases, please keep this in mind when responding (hopefully).
Regards
Grahame
Who/What is asking for the password? The operating system? Or Access itself (does the access program open before the password is asked for?)?
Quick fix would be to grab the original and place it in the required location instead of the robocopied one. Also there may be permission issues on the file itself rather than the directory.
Currently, I am syncing a WordPress project database between myself and my team via Dropbox. I notice that Dropbox never syncs the database after I make changes to it until after I have stop the servers in MAMP. This is causing conflicts occasionally if more than one member of my team edits the same database entry on their local machine and then each person closes their respective MAMP servers at different times.
I'm assuming this is because MAMP is locking the database folder while it is in use. Is there any way to prevent MAMP from locking this folder or to give Dropbox privileges that extend past MAMP's file locking?
I would greatly appreciate any help!
File locks are there for a reason. Attempting to bypass the file locking mechanism just seems to be asking for a corrupted database.
Although not at all practical nor safe, your team members can copy the file from their dropbox directory a non-synced directory make changes and overwrite the database file in dropbox. But this opens the door to overwriting others work if the version copied isn't the most up to date version (obviously).
A practical and safe solution is to connect to 1 database server and team members will be able to safely make changes on the server (and obviously everyone will have access to the most up to date version).
I've taken over an old software project which uses an MS Access database to store its data. However the database won't open in Access as it says:
"You do not have the necessary permissions to use the 'database.mdb' object. Have your system administrator or the person who created this object to establish the appropriate permissions for you."
But I have no idea how to do this and googling reveals almost nothing (it seems restricting access to Access databases it not something that's done very often!). The only other clue I've got is there's a .MDW (workgroup) file in the same folder, but I don't know if (or how) this relates to the main database as it has a different filename and also doesn't open.
How can I get access to this database? Is it likely to be password protected or just some kind of permissions problem?
The chances are pretty good that the .mdw file is the workgroup file for that .mdb database. (The .mdw file does not need to have the same name as the .mdb file because several different .mdb files can all share the same workgroup security settings.)
To access an .mdb file that has user-level (workgroup) security enabled you need to open it using a shortcut (or command-line invocation) of the form
"C:\Program Files\Microsoft Office\Office14\MSACCESS.EXE" "C:\Users\Public\uls\ulsTest.mdb" /WRKGRP "C:\Users\Public\uls\Security.mdw"
For a more detailed write-up, take a look here.
Is it possible to attach a database that is stored on a remote server because when I mapped a drive and tried to attach it in management studio, the drive does not show up as an option. I moved it because of disk space and if I cannot what is the alternative suggestions?
You should be able to attach a database on UNC path (I wouldn't use a mapped drive - that drive is mapped for you, not the SQL Server service account), but you have to ensure that the SQL Server service account has read/write permissions on the remote folder, and you have to run trace flag 1807 (please read Brent Ozar's post about this).
Also don't use the GUI for this. Once you have the trace flag set, have restarted the service, and have configured permissions correctly, use a new query window, and run the following command:
CREATE DATABASE db_name
ON (Filename = '\\uncpath\share\file.mdf'),
(Filename = '\\uncpath\share\file.ldf')
FOR ATTACH;
(The UI is never going to offer you a UNC path no matter what trace flags you have set or what permissions are enabled.)
Be prepared to handle a corrupted and possibly unrecoverable database should the network share go down, of course.
If that sounds scary to you, good! It should! This is not a good idea at all. Instead you should free up some space, add a drive, or host the database on a different instance.