How to handle Onedrive duplicating accdb files? - ms-access

We currently have a shared Access database in a Onedrive folder.
User interacts with the file via an excel file with read\write functions. E.g. dbInteract.xlsm
Otherwise, nothing else interacts with the accdb file. The excel file points to a specific accdb file name. E.g. myDb.accdb
Problem arises when (I think) there is an syncing error and one user interacts with the database anyways.
Onedrive creates duplicates of myDb.accdb and names them myDb-user1.accdb etc.
The file myDb-user1.accdb becomes the latest updated file while myDb.accdb remains untouched.
When user retrieves info via dbInteract.xlsm, info retrieved is still from the myDb.accdb file (the file that was not updated). This has created confusion amongst users and they would try to update the database and it reflecting that nothing has changed whilst unknowingly create more accdb files on the Onedrive.
Issue resolves itself once the spare databases has been deleted but was wondering if there can be any preventive measures I can use.

Related

How to modify Access DB File which is in sharepoint Document Library

I am having accdb file(Ms access DB file) in sharepoint Document Library. I want edit the file in browser or without downloading the file to the local.
I am able to view the file but not able to Edit it.
Need help
Access doesn’t really work this way. You can store the data tables in Sharepoint, but you still need the local access file to interact with it. You can link to data tables in Sharepoint. Instead of creating a brand new table, you import the data source.
Microsoft does have a newish program out now called PowerApps that may help you accomplish something closer to what you’re describing.

MS Access 2013 export query-to-XML not saving file

I'm trying to save several of my queries as XML files in order to re-assemble my database in another location where the only viable transfer method is text or XML files via email (long story).
When I use the built-in export function, Access allows me to select a save location and nest the schema inside of the XML file, and then says that the export was completed successfully. The file is not in the destination folder, and no error was thrown.
This only happens when exporting bound queries. Other Access elements (tables and forms, for example) export just fine.
If I watch the folder during the export process, I see a file appear very briefly, and then dissapear. Has anyone else experienced this?

Why is the Microsoft Access Linked Table Manager not updating a linked *text* file to different file name?

In Microsoft Access 2010 I am attempting to change a linked text file to point to a similar file with a different file name. However, after relinking to the new file, I discovered that my linked table was still pointing to the original text file.
Here are the steps I was taking:
I open the Linked Table Manager, then browse to the new file name...
After selecting the new file, I receive the following message that everything is good to go!
However the linked table is still pointing to the old file!
Am I doing something wrong here? Or is it expected that this would work differently for text files, and require deleting and recreating the linked table?
In VBA I can automate the relink, but it just seems odd that the wizard would not function consistently between different types of linked tables. (For example, I can use this same process to change the link to an Excel worksheet in a different file, and it relinks just fine to the new file.)
I think you should compare this with other linked tables (MS Access of MS SQL Server). What you can choose using the Linked Table Manager isn't another table but another database, the table names must be the same. Linked text files must be seen as tables, their containing folder must be seen as the database.

Distinguish between renamed .accde file and .accdb file

I have been given an Access database .accdb file by a client to work with. When I open it and try to open a code or form design window, it reports that it is an .accde file (with no code). Is there a way (with a hex editor, for example) that I can prove to my client that this is a renamed .accde file, not an .accdb?
Make a copy of the original file, and save it as an accde file.
Create a new small database with just a splash screen and save it as an accdb file.
Copy that file, and then convert it to an accde file.
Schedule a 15 minute meeting with your boss and show him all 4 files.
Unless he just fell off a turnip truck, he's going to see the difference between when an accdb and accde file open (i.e. your newly created files), and see that the original accdb file opens with the exact same message as your accde copy and your newly created accde.
If he can't put 2 and 2 together, schedule a meeting with his supervisor and ask for his job.

Cannot open .accdb files because Access looking for hard-coded path

I have received a few .accdb files from a client, and I am trying to open them in Microsoft Access 2013. The files seem to open correctly, but whenever I click on any of the tables or queries on the left I get the following error message:
C:\[hard-coded path on client's computer] is not a valid path. Make sure that the path name is spelled correctly and that you are connected to the server on which the file resides.
Now, I know that the path does not exist on my computer. But why is Access looking for a hard-coded path on another person's computer? And how can I access the tables and queries in Access?
Additional question: Is there an easy way to import the data to SQL Server instead? I read a couple of posts about importing data from Access to SQL Server, but apparently the SQL Server Import and Export Wizard is expecting a file of a different format, not .accdb.
Thanks in advance.
You need to get the back-end database file from your client. All the tables are stored there. Once you receive it, save it at a convenient location on your computer and use the "Linked Table Manager" on the "External Data" tab in the .accdb you already have. That will allow you to update the table links for the current location of the back-end database file on your system.