I have an MS Access (2013) application with a split database. Everything seems to run smoothly except for occasionally I will get Error 3048: Cannot open any more databases.
The error occurs when the front end tries to run vba code which involves pulling data from the back end and will stall on any line with: Set DB = OpenDatabase() or DoCmd.RunSQL() commands.
The strange thing is that this error seems to be time based. I can access the back end hundreds of times without error if I do it quickly enough but after some time has passed (~1 hr) the error shows up. In fact, I can open the application and leave it running in the background (with no code running) then go back into it after an hour and I will get the error the first time the code tries to open the back end.
I've searched the length and breath of this site and google for solutions so I know this error has been addressed before. To save people reiterating the usual fixes I will list what I've tested for so far with no success:
Recordset limit: I'm not leaving any recordsets open, every time I open one I make sure to close it. The same for the databases. All my requests
to the back end are done via 3 or 4 vba functions and each of these has
a Rec.Close or DB.Close corresponding to every OpenRecordset()
and OpenDatabase() and I never have more than 2 recordsets open at
a time.
Control limit: I have 151 controls on the biggest form in the application so I should be below the limit (I believe this is 245 for a single form?)
Corrupt database: I've copied all my forms and code to a new Access database and run a Compact and Repair.
Machine Issue: I've tested the application on several machines and reproduced the same error.
Anyway with most of the above situations I would expect the application not to run at all, instead of running fine for a set amount of time and then crashing.
Some other points of note:
Citrix Users: The users are split between normal windows machines users who are experiencing this error and others who are using the application through a virtual desktop software (Citrix) who are having no issues. Unfortunately I don't know enough about this virtual desktop to really work out what that implies.
Background vs Foreground: Some users have claimed that the application only crashes if it has been running for a long time AND they switch over to another program and switch back. I've confirmed that simply switching between the application and other programs doesn't cause it to crash but haven't yet been able to leave it running in the foreground long enough to confirm if it crashes without switching between programs.
I've been struggling with this for days, anyone able to help me out?
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.
Every time I use the MS Access Immediate Window within the VBA Editor, Access crashes if I type any procedure name followed by the spacebar.
For example, I have a procedure called "CreateCEUploadFile" which takes a string parameter for a year. So, I'd like to type "CreateCEUploadFile "2019". However, as soon as I hit the spacebar after the e of File, Access freezes for a second, then crashes.
I initially thought this was specific to a database I've created. This is a database which was initially created 7 years ago, and has been worked on steadily over that time. So, I tried:
Compiling, then compacting and repairing. No change.
Decompiling the file. No change.
Re-compiling the file. No change
Creating a new database file, importing all objects. No change.
Restarting the PC. No change.
Removing Office (Office 365 Pro), restarting the PC, re-installing Office, re-starting the PC. No change.
I've now experimented, and discovered that the same issue occurs in all database files on this PC (a laptop that I've been using without issues for around 2 years). It also occurs with any call to any function (whether my own or built in), as soon as I hit a character after the function name.
In the immediate window:
? now --> works
? date --> works
? format( --> crashes as soon as I hit the spacebar`
I have now just discovered that this same issue occurs in MS Excel's VBA Immediate Window too...
Okay, so I've just found the solution.
Using the old principle of "What's changed since I last got this to work" I discovered that it seems to be a problem with my installation of Dextop.
I wanted to have a way of having multiple virtual desktops, and the built-in virtual desktops system in Windows 10 wouldn't cut it. Every time I do anything in SSMS on one desktop, it's reflected in the other.
So, I had a look around and found good reviews for Dextop. It seemed to work well - I have two different databases open in Access (one on each Desktop), and two different instances of SSMS, one pointing at each server. However, it seems to be this that was causing the Immediate Window to crash the relevant application.
Exit Dextop - all works well.
Restart Dextop - symptom immediately re-appears.
So now to try to find another alternative to Dextop....
I have an Access database that was designed and developed back in 1997 - 99. all user interaction is through forms and reports, there is no end user access to the backend tables. It has worked flawlessly for the last 19 plus years. Both front and back end are still in .mdb format, but the front ends which are local to the workstation and are replaced with a clean copy upon every login are running on Access 2016. There are at a maximum, 6 users in the database at one time, usually there are only 4.
Starting about 90 days ago the back end would randomly corrupt when a request to write a record was made. The error message is “Database is in an unrecognized format”. We have replaced old workstations and the Server that host the back end, in addition we replaced the switch that all computers connect to. On the workstations that were not replaced Office has been re-installed and all updates applied to it. The corruptions cannot be reproduced consistently, it happens in different forms and from different workstations randomly. After the corruption, we have to delete the lock file, compact and repair the Back end and it will work just fine until the next corruption, and the data that was attempted to be written is there, so there has been no Data loss.
The back end data was rebuilt last year to remove the random primary key values, that were created when the database was replicated over a dial up modem back when the database was first developed. The replication functionality was turned off approximately 17 years ago. The back end has been rebuilt again from scratch, each table was created in a new Database and all the index's and relationships were rebuilt. The data from each table was exported to a Text file and then imported into the new database.
There were no changes made to the front end in the prior three or four weeks before this issue started happening. Just to ensure that it was not something in the frontend, it was rolled back to a version that was working fine in February of this year, unfortunately that did not resolve the issue
None of these steps have resulted in resolving the back end corruption, and if anything, the corruption is happening more frequently. The only thing that works at this point is to have one user at a time in the database, as soon as the second user opens the frontend, the back end will corrupt within a few minutes.
Any thoughts or ideas would be greatly appreciated.
Thank you
Steve Brewer
Update:
This is a known bug introduced by one of the Office/Windows updates. See http://www.devhut.net/2018/06/13/access-bu...ognized-format/ for all the details and workaround/solution.
I recently upgraded from 2005 to 2012 (about 10 months). When I first started using SSMS2012 it worked great was able to open multiple windows in a particular database. For about that last 2-3 months SSMS hangs when I try to open more than 1 query window or open a file. It is random but happens a majority of the time. I have been able to interrupt the hang a few times. When I interrupt it I get the login screen and it sits there trying to log in apparently unsuccessfully. If I cancel the login and try it again with the same entries it connects just fine and things are great, but I have to do this for every window and I cannot often break into that screen before it stops responding.
I have searched extensively and have not found an answer to this problem. It only appears to be happening to a particular instance. The instance does not show any signs of issues, has been rebooted and configuration checked for inconsistencies, etc. I am at a loss. If anyone has experienced this and has been able to resolve it I would appreciate a response.
Again this is a fresh install of 2012 standard with 2005 imported databases. All indications show that it is working fine. compatibility level for a majority of the databases are still 90, until I can clear them for 11 with the software they house. I have a test environment with the restored versions on a different server and no issues result from that instance - I can open up multiples without incident. My belief is it is something with that particular instance, but I am not sure where else to look.
Thank you in advance.
My Application (Vb.net, Access 2003/2007) is to scan Access Database files for activex controls and to generate report accordingly.
Problem:
Getting an error like:
"Insufficient memory to continue the execution of the program."
The above error occurs while scanning for older version of Access files like prior to office 2000.
And the line of code where I get this is as follows:
Dim oForm As Access.Form
Dim oAccess as Access.Application
oForm = oAccess.Forms(objForms.Name)
But it opens the file and form as well.
Need Help:
Whether it is possible to read the file (Access Forms and Reports) or not?
Please provide me reference or any solution.
You appear to doing COM automation of Access to open the forms and then cycle through their controls looking for certain properties.
Another solution would also involve automating Access, but it wouldn't require actually opening the form, and that's the undocumented Application.SaveAsText command. You'd do something like this:
Application.Saveastext acForm, "dlgWebBrowser", _
"C:\Output\dlgWebBrowser.txt"
You would then have to figure out how ActiveX controls are described in that file. If that file looks like the code for a VB form, that's because that's precisely what it is.
The example above had an IE web browser control on it, and after a dump of OLE data, it had this in it:
OLEClass ="Microsoft Web Browser"
Class ="Shell.Explorer.2"
GUID = Begin
0x54c1ea41936d2046b9dc5b29905976e3
End
I would expect that all ActiveX controls will have an OLEClass, but I non-native avoid ActiveX controls on principle because of the problems they can cause if not properly installed when you try to run the app.
In fact, that could be the source of the problem -- if you open the Access form on a machine that doesn't have the relevant ActiveX control registered, it's going to fail, and the form won't open.
My bet is that Application.SaveAsText is going to sidestep that problem entirely, since the form doesn't have to be opened.
I've seen behaviour very similar to this before. Access 97 files will sometimes report an 'out of memory' error if you try to open them on a computer with more than (I think) 1Gb of RAM. The error doesn't always manifest itself immediately - sometimes the project can appear to run normally but crash when you try to open a particularly large object.
In the case where we did run into this the users were running an old Access 97 database on new XP machines they'd been upgraded to with modern amounts of RAM. Tech support for the company tried everything they could think of - including complete office reinstalls, applying all patches etc. but eventually had to resort to removing RAM from the computers - whereupon the errors went away and everything was rock solid again. I am uncertain as to the exact cause, but it will be connected with memory management in the Access 97 file format (I believe the error is on MSDN somewhere but I wasn't directly involved with Tech support hunting the solution down - I'd just written the application many years before)
I'd suggest you're only way out is to use a special, low memory, PC to run the application.