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.
Related
I have a form with a button which opens a new form to add a new record to a table.
In Access on my PC (full version), everything works.
When I try to run it on a server with Access Runtime, I get an error saying something like:
this application has stopped working due to a runtime-error. The
application will now be closed
(I have the Dutch version, so I hope this comes close to the English dialog box message).
I debugged the VBA, but that doesn't seem to be the problem.
It has worked before:
Private Sub Knop62_Click()
DoCmd.OpenForm "Machines Toevoegen", , , , acFormAdd, _
acDialog, OpenArgs:=Me.Installaties_Id
End Sub
Well any un-handled error in the runtime will spit out the error message, and then as you experienced exit the application.
there are a good number of ways to approach this:
Improve error handling - make sure you don't encounter any un-handled error. I find this can be a LOT of work.
Another way? Compile your application down to a accDE. When you use a accDE, not only does the runtime ignore errors, not only does it NOT shut down?
It also means that all of your local and global variables are NEVER re-set. so global vars, and even global reocrdsets or anything else will retain their values, and do so even with errors. As a result:
Your application runs like a un-stoppable fright train.
Your local and even global variables retain their values. This allows use of application wide settings and variables that never re-set. And no re-sets ever occur even for un-handled errors. They remain intact for the given session (since the time the application was launched).
So, I would try running your application as a accDE on that server. It will not only become vastly more reliable, but it will also not shutdown on un-expected errors and even better it will retain the value of variables even when having encountered errors.
So it looks like you have some un-handed error. You can go on a treasure hunt to find this error, or just try a accDE in the meantime, and perhaps in the new years you might eventually track down the error or issue. But until then, just compile your application as a accDE.
To compile:
First, from VBA editor (just hit ctrl-g). And from the menu bar choose debug->compile. You MUST ensure that no compile errors exist before the next step.
If above compiles, then from UI (main ribbon), go file->Save and publish
From that panel, choose Make ACCDE.
Access will compile your application into a "access executable". Now try running this application with a accDE file extension on the other computer.
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 have a Word Template with VBA.
Wherever I need to I handle my errors with either a "On Error Resume Next / On Error Goto 0" round a call to a collection that might fail, say, or a full error handler (On Error Goto label: / Resume exit_label:)
Tools Options is set to Break on Unhandled Errors
I have found that for this template (only it seems) that unhandled errors are not being reported. The VBA code just stops running without telling the user anything.
I have tried exporting all VBA modules / forms, saving the template as a .dotx, closing and reopening then saving as a .dotm again and adding the code back but same problem persists.
Other templates for this client work fine. A deliberately added delete for a non-existent bookmark causes an error to be shown. The same delete call is ignored by the iffy template BUT the code stops running so it isn't doing Resume Next.
If I add a full error handler to the procedure concerned it does error and reports via my msgbox code.
In some respects this wouldn't matter, anywhere I am expecting errors to be a possibility I handle them but I have a certain amount of code that deals with images in headers and they are prone to errors. At this point I want the code to error where they happen so I can analyse how to get around the error, just telling the user isn't going to get the template working. What I have at the moment is the code "dying" and it is very hard to track where without putting in loads of debug statements and seeing where they stopped.
Has anyone seen something like this before? Could I have set something for this template specifically to tell it to not error on unhandled errors?
Other templates on the same machine error quite happily.
The template is very complex so I don't have the option to make it from scratch. Turfing out the VBA and putting it back didn't fix it. If I have to I can add handlers for all procedures but that shouldn't be necessary as errors won't happen once I have tightened up the code.
Any help really appreciated - for a few days I thought it was just VBA dying when working with images, now I really it is something more general than that.
Ok. I have found the source of the problem.
I had used a couple of standard procedures we have in various projects for conveying busy/not busy to the user - we call them InterfaceOn and InterfaceOff. They change the cursor, switch off screen updating, etc.
One line for the Off proc is "Application.EnableCancelKey = wdCancelDisabled".
I hadn't realised how severe that line is, it appears to stop the errors being reported and the code just dies. The help for it warns it is risky but doesn't explicitly state that it'll kill VBA on an unhandled error.
The InterfaceOn procedure has the line that reverses the EnableCancelKey restriction.
These procedures are used a lot so I am surprised this issue hasn't shown up before. Have removed the EnableCancelKey lines for now. No particular need to be that dramatic with this project.
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.
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