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
Related
I have an old Access solution that includes opening a connection and inserting some lines in a SQL database. I had to make a very small change that had nothing to do with that connection. After the change I compacted the database.
The solution works normally for me, but the person that normally runs it is getting the Run-time error I outlined in the subject. I had another user try and also got this error. It seems I am now the only one that can run this, yet I did nothing to the code or the access db as a whole that I can see explaining this.
The button they press that triggers the error:
Sets a variable as ADODB.Connection
Defines the connection string
ERROR TIME: Then it runs a function that executes a stored procedure using that connection. The error point is showing as occurring at the top of that function, when it attempts to CreateObject("ADODB.Command").
Run-time error '429': ActiveX component can't create object
Can anyone offer anything as to why this user that could work with it suddenly can't despite the same security, same machine, etc.
Sigh... Thanks for the responses. It turns out to be our security software and the fact that I moved the solution to a different location. Out of sight out of mind. I forget that I have some exemptions setup for myself, so I didn't see how it could be that. I just need to learn to check that stuff first.
When trying to add external data in excel, the data connection wizard does not load properly for some reason.
I select Data,> From Other sources, >From Data Connection Wizard>My Data source>table i want...
Then I have no options to set parameters, can only click "Finish" without any query set up.
Just Defaults to "Select * FROM XXXXX"..
Anyone have any ideas as to why this would be the case?
I have done this exact same process before, on multiple occasions, with to issue.
Something has changed to make this process not work properly.
There are big changes going on in the excel data input environment recently and all the process are being remodeled and reworked. I checked my excel 16 and it doesn't even list the option you mention (Data connection Wizard) anymore. I feel a strong push towards Data model which may not suit me or other, but all other connection methods are gradually ceasing to work.
I would guess you perhaps do not have a latest Excel version and so it just happens.
I've been trying to create a macro that is run via a batch file to generate a report and have been having some massively annoying issues with connecting to a SQL Server, probably due to some stupid mistake on my part.
My code to create a connection is as follows:
Dim dbs As Database
Dim qdf As QueryDef
Dim rst As Recordset
Set dbs = OpenDatabase("", False, False, connect)
Set qdf = dbs.CreateQueryDef("")
where 'connect' is a string containing connection details.
My problem is that Excel (2007) seems to have a problem with the very last line of that block, for whatever reason. I've added a watcher to the dbs variable, and it seems perfectly fine, so then why does it not like qdf?
The even stranger thing is that, if I put a 'Stop' command at the very beginning of the macro, start execution from the batch file, and then continue manually upon reaching the Stop, it works perfectly and does exactly what I'd like it to.
I've tried looking at DBEngine.Errors, and that tells me that I have the following problems:
General error: Invalid window handle
Connection not open
Again, this makes no sense to me, especially given that it works under manual execution, and Google hasn't yielded any answers.
P.S. If this is unclear, please also take a look at this question, which seems to be asking the same thing, but has no answer.
So, using the scientific method, a co-worker and I were able to figure out what the issue was, though I have no idea how it makes sense or why it would even be an issue in the first place. The layout of the macro was, in a rough sense, as follows:
Test database connection and close it
Create new workbook
Connect to database again and populate workbook from database calls
For some reason, however, the solution ended up being that VBA didn't like the fact that we were doing connection stuff both before and after creating the workbook. Changing the program flow to:
Create new workbook
Test database connection and close it
Connect to database again and populate workbook from database calls
did the trick. Again, I have no clue why this solved our problem, or if changing the order of this sequence changed something more significant within the code, but it works now! If anyone has any ideas as to why this might be, feel free to comment.
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.
After a whole day tracking down a memory leak in my VB.NET project, I have traced the cause to a bug with FileMaker's ODBC driver !
To reproduce you'll need a database you can connect to (I have mine hosted on Server Advanced 11.0.3, but you can also host it locally), and the ODBC driver registered/installed on the PC (I tested versions 11.3 and 12.0, and the latest 12.2).
Start a new VB.NET WinForms project, add a button to the form and paste this code onto the button's click event:
Using cn_FM As New Odbc.OdbcConnection("DRIVER={FileMaker ODBC};SERVER=192.168.1.xxx;UID=admin;PWD=admin;DATABASE=test;")
cn_FM.Open()
End Using
All this code does is open a connection to a FileMaker database, however if you analyse the memory usage in Windows Task Manager you can easily see (by repeatedly clicking the button you just made) that cn_FM is not being disposed properly because the Handles keep increasing! I tried forcing Garbage Collection but this didn't do anything, so I assume its a problem with the driver itself.
Oh, and I tested connecting to a SQL database in the same way, and as you would expect, there was no handle leakage...
Can anyone confirm this is correct?
Edit: I tried various ways of opening and closing the connection, as well as actually querying the database for something in the using block. Also tried hosting the fp7 file locally, but still no go :(
FileMaker's ODBC drivers are horrible and they admit it. You'll also find that your CPU spikes to nearly 100% for every query you hit the FM server with. I've been griping at them about it for years.
Their "solution" was to introduce External SQL Sources, but that requires you to go the other direction. You can bind your VB database to FileMaker and then access the data just like actual FileMaker data. This will allow you to create scripts on the FM server to sync whatever tables you need to sync with your VB database.
It's not ideal, but that's going to be your best bet to get something together with good performance.
I got around this problem by making a persistent connection (declare and open it once and leave it open). But I need to check if its still open each time I want to use it, for example:
Public Sub CheckOpen(ByRef cn As Odbc.OdbcConnection)
If cn.State <> System.Data.ConnectionState.Open Then
cn.Close()
cn.Open()
End If
End Sub
If you have multiple FM database files then this may mean you need to have one connection for each file.
Side Note: FileMaker's xdbc_listener.exe process running on FMSA is also leaky. We have noticed a pattern that once it reaches just under 2GB memory usage it crashes. So keep in mind that the process may need constant restarting.