I have an MS Access split database and I'm trying to get it to work with the backend on a new, more secure drive on our network. I've used a UNC path for the backend location.
This database has been running without problem on another drive which is totally public to everyone in the company (~4k people, not secure) for about a year. We have a generic account for users to access the database throughout our factory and haven't encountered this problem before I tried to switch it to the new drive. I've contacted our IT department and they've given myself and all my user's accounts read/write access to the drive, but only I can run it.
Other user accounts get these problems...
All of my forms with objects bound to a table immediately throw a runtime error before even getting to Form_Load.
My userforms will run DLookup functions and execute message boxes but throw a runtime error when they go to execute a query.
I've tried using an 'On Error goto' to try and actually find the problem but it throws a runtime error before that.
I can't think at all what the problem might be. IT have told me I have the same permissions as the other users. Any suggestions on what to do?
In the front end of your DB you may have to change the path which links to the tables. The tables are in the back end of the database, which you have now moved and therefore changed the filepath. the frontend wont find them. You can delete the table links in the front end then use External data > import and Link > Access. In order to re-link the tables using their new filepath. You would then need to redistribute your frontend to the users.
I'm not sure if you have already done this, however, you haven't suggested so in your question. hope this helps, apologies if it was helpless.
I hope you have found an answer to this. I wanted to answer as well, because I had the exact same problem yesterday. It turned out that the location was referring other users back to the folder's shortcut name versus it's full length name (it is called the W drive on my computer and the K drive on theirs). I solved the issue by spelling out the name in full.
Related
I ended up corrupting my database to where every time I attempt to open it, I get error 3022, "changes you requested to the table were not successful because they would create duplicate values in the index."
Recovery of the file does not seem possible and my previous back up is a month ago. I have been able to extract everything but the Modules, which is what I need to recover the most. None of the standard ways I have found work because they require the ability to open the database (For example, trying to set it as a VBA reference still give the same error.)
Is there any way to get the modules or code out of the file without opening it?
Edit:
Was finally able to get access to the file. Using DBEngine.CompactDatabase it was able to do a compact and repair. The issue has boiled down to the "MSysAccessStorage" table is corrupt, and says "Id is not an index in this table". I know have access to everything, except the modules, which I can't open without the MSysAccessStorage working.
I'm going to keep poking at it but I'm not sure what options I have for fixing a system table. Any ideas would be helpful.
Unfortunately, the Visual Basic for Applications project has been corrupted. The original database doesn't even have any VBProjects when listing a count. I'm going to call this one a lost cause. Thanks everyone that tried to help.
I have SQL Developer on machine. Once while exporting data from database to my local drive, It prompted me to ask whether " you would like to allow the local drive to be writable or not". I accidentally clicked No. From then, I am not able to export any file from database to my local drive. Every time I get an error saying "Save as Target :D is not writable". I couldnt find any solution in the preferences section nor over the internet. I am accessing SQL developer via citrix. I have cleared cache, removed tmp files. Nothing helped. Is anybody facing the same issue? Any idea how to clear defaults? I use Windows 7 environment.
Even I faced this issue and googled but no luck. So, I started trying multiple options. Below one worked (exclude the double quotes as slash is lost while posting this update)
\\Client\C$\Test.txt
Example : \\Client\C$\Data\Test.txt
I am developing a winforms application in Vb.net
when i try to add a tableadapter to an existing dataset I am receiving the error:
Failed to open a connection to the database.
"An attempt to attach an auto-named database for file ###Filelocation### failed. A database with the same name exists, or specified file cannot be opened, or it is located on UNC share." Check the connection and try again.
This same dataset has 2 other tableadapters using the same dataconnection (as I am selecting the already existing dataconnection) which work fine
this connection is using application connection strings:
Data Source=(LocalDB)\v11.0;AttachDbFilename=|DataDirectory|\test.mdf;Integrated
server=localhost;user id=root;password=password;database=testuser;persistsecurityinfo=True
this error pops up every time I select the dataconnector on the first window that pops up.
Why is this happening
additional info:
The other 2 tableadapters were added to this dataset using a different computer
this is for a mysql connection
I found this post on the MSDN forum:
An attempt to attach an auto-named database ....\aspnetdb.mdf failed
One of the suggestions is as Mr. DonBoitnott correctly says, add User Instance=True;. But, there's also another suggestion posted by Luke A.
"For the record, not one single error message given to me during the course of trying to fix this was relevant to the actual problem. Upon first receiving "An attempt to attached an auto-named database..." I looked online for every suggestion I could find: use an absolute path to the MDF, reorder TCP/IP and named pipes in the server configuration, disable/enable UserInstance (depending on where you looked), change security settings, reconfigure authentication, give specific login credentials.
None of these worked. All of these led to different vague/ambiguous error messages, which led to another problem which required a solution which led back to the original error message... an endless loop of problems, completely unrelated to what was actually wrong.
_Also, posts about setting correct permissions on the App_Data folder are deceptive, as they imply the default permissions were not sufficient for SQL Express (in fact, they are). The whole point of this VS environment is that you can develop a web application and plop it right onto an IIS/SQLExpress setup and have it work. This makes the applications more portable (within IIS, of course) and secure. Of course, everything configuration-related has been obfuscated enough to make it several orders of magnitude more difficult than it has to be."_
So: Try prepend Initial Catalog=uniquenamehere to your connection string.
Though he says "... where 'uniquenamehere' is some name for your project.", try replacing uniquenamehere with the actual name of the database where the table exists.
the file is a .mdf file so it is a mssql file
my guess would be that as you stated you are using mysql the connection string has to be a tad different and therefore the Dataset can't connect to Mysql
Try adding User Instance=True; to the connection string.
Ok, our current problem is the classical "trying to allow multiple users access onto one fe file (this is in runtime currently)" - This cannot be handled (at least in AC2007) and is best solved by installing a FE on each computer that is using it.
This poses another problem for us, we have many employees who we want to be able to have access to it, yet the program probably doesn't warrent our techs to push out updates of this file to each computer with their "patches" (plus there may be added costs to doing such for us).
We would really prefer the ability for users to open a link from our internal portal to the file as can be currently achieved. We are mulling over the possibility of pushing out 4 or 5 copies of the FE application on a shared folder and creating an Access program that would essentially check to see if a FE app is open say FE1 and if so it would open FE2 (and so on) then close the sharepoint linked database that did the checking so a new user could open that. This would allow multiple users access to the same BE information using the same FE program.... would this work? Any ideas of how to go about it?
Yes it works, the idea is to create a function that checks for the open file, if it finds its open it replies with an error, on the error you can move to the following database. Here is a sample code:
Option Explicit
Function FileLocked(strFileName As String) As Boolean
On Error Resume Next
Open strFileName For Binary Access Read Write Lock Read Write As #1
Close #1
If Err.Number = 0 Then
Application.FollowHyperlink "c:\MasterMAX.accdr"
DoCmd.CloseDatabase
End If
If Err.Number <> 0 Then
Application.FollowHyperlink "c:\MasterMAX2.accdr"
End If
End Function
Disclaimer: I don't know anything about SharePoint, so I can't say if my proposed solution is still viable when SharePoint is involved.
If your problem is just how to distribute the file to all machines, why don't you let your users start a batch file that copies the Access frontend from a network share to each machine and starts it?
We are doing something similar at work (without SharePoint, though), and I described our setup here:
How to automatically update MS-Access 2007 application
We have put the batch file on a network share as well. The users have just shortcuts on their desktops to the batch file on the network share, so it's easy to update the batch file as well.
Maybe you can do something similar (let the users run the batch file from SharePoint, which copies and starts the Access frontend).
Just a little background: I am using Access 2010 to create forms and VBA code in an Access 2003 format database. For some reason, Access 2007 format databases always corrupt on me when I make changes and save them with a particular group of objects, but that's for another discussion.
When writing VBA code in this Access 2003 database, any time my code breaks (via breakpoint or an unhandled error) and I make a correction, Access tells me that it can't save back to the database because another user has it open. However, I am the only user working on the database; this is a local copy of the database and it's sitting on my desktop.
The LDB file can't be deleted because Access is using it. When I first load the database, I see my machine name and "Admin" when opening the LDB in a text or hex editor. After a break, I see that plus a duplicate entry, but this time around "admin" has a lower-case "A."
Closing the database and reopening it fixes the problem but makes it needlessly cumbersome to debug my code. Anyone else encounter this issue and/or have a fix for it?
It might be helpful to know what your code is doing when this happens. Certainly that's not normal behavior. For instance, are you opening another database with New Access.Application? Are you using ADO or DAO to access records in the database with a connection string?
There are no external connections to the database at all.
It may not matter if there are external connections to the database if you are using a connection string to connect to the open database; not sure but that may be seen as an external connection... you may want to use CurrentDB for DAO, or CurrentProject.Connection as your ActiveConnection for any ADO queries.
I am assuming that this problem persists through reboots; but for the sake of argument, try closing out Access and going to the task manager to make sure you have no other instances of MSAccess.exe running. You might even try closing all Office products and/or making sure that Access is the only Office product running. I have seen some weird conflicts between Microsoft Communicator and Outlook; so it's not entirely out of the question for Access to have issues with another MS product.
You may also want to check the size of the database to make sure it's not exceeded 2GB. That causes the infamous "Invalid parameter" error; perhaps it might be causing this as well.
With no other details about how your program works, we may only be able to offer generic advice like this.
I have discovered a way to cause the problem discussed above (and thereby to correct it). Turns out if you create a database object and set it to the current database, you get this problem.
That is,
dim cdb as database
set cdb = currentdb
From this point on, you're cooked.
Instead, figure a way around this by possibly using currentdb directly or not using it at all.
This worked for me.
In your VBA Try checking that all your open Connections to the database are closed. Until the connection is open the LDB fill will be there.
Same symptom of not being able to save form or code mods after application had started. I found a workaround today! In the startup of my first form of the app, I had issued a "DAO.DBEngine.SetOption dbMaxLocksPerFile, 20000". Commenting this statement removed the problem. I did no further testing, but FYI, the DBEngine call was before any reference or attempt to use CurrentDB(). Also the current default on my Access 16 install is 9,500.
I thought I might answer here, since I stumbled upon this question while having a similar issue. Essentially, it boiled down to this: I could either edit forms, VBA, etc. or edit information in the local database (which I'm using as a cache) with currentDB. I also have a backend database, but the locking was clearly on the frontend database.
The solution ended up being weird, but stupidly simple. When the frontend starts up, I have it immediately create a connection to the backend using OpenRecordset (and similarly to you, that backend was still on my own computer for testing purposes). I tried temporarily disabling that code, and suddenly it wasn't an issue anymore. And it turns out, once I call currentDB, I can then call OpenRecordset to open the connection to the backend, and suddenly it isn't a problem anymore.
Tl;Dr: if you're calling OpenRecordset somewhere in your code to connect to a backend, be sure to call something like set db = currentDB beforehand, then everything works. (That is, probably until I publish this answer and Access then decides it doesn't want to anymore).
Why this fixed it is beyond me, someone with more knowledge can maybe answer that.
The solution:
options > current database > click enable -track name auto correct info