Runtime closes when I use DoCmd.OpenForm - vba

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.

Related

Getting Error 'HasFile' is not a member of 'FileUpload' VB.NET

I randomly get an error saying HasFile is not a member of FileUpolad.
I'm using a file upload button to upload images to a server. This usually runs; however, every once in a while it errors out. Sometimes the error is caught by Visual Studio during run time, other times it will be a Server Error in Application. Compilation Error when I load the page in debug mode. I've check dependencies and everything seems to be fine. Even the IntelliSense brings up HasFile with I am writing the code.
Usually re-writing the line or restarting Visual Studio resolves the issue, but it keeps coming up randomly.
I happened to figure out what the problem was. Since it was my first time doing this I had a test class in the solution. The test class was named FileUpload. Rookie mistake. I can't believe I didn't catch that earlier!

MS Access occassional "Cannot open any more databases" error

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?

Microsoft crash upon reaching "End Sub" in VBA for MSAccess

I'm having a problem with a form that adds a source association to a company record. In the main form, the user specifies the source name to be associated, and then this form opens to allow the user to confirm the name, and pick a year, if that name has more than 1 year associated with it. When the user clicks on "Continue", the code checks if the association already exists, whether the source has multiple years, and if so, if the user has selected which year to put with the associated name. When there are not multiple records (ie the name has only one year,) the continue button works just fine, but when the user has to pick a value of the year, the continue buttons works fine and does its job, entering the new association into the database, until it gets to the Exit sub line under the Exit_cmdAssign_Click line, and then the whole Access stops. I get a message box saying "Microsoft has stopped working", it backs up the database and eventually reopens it. At one point, as it stopped it gave me an option to debug in Visual Studio, but there, there were problems finding necessary files for the debug. Before I tried to debug, it said, "An unhandled win32 exception occurred in DWWIN.EXE [8940]."
Does anyone know how an exit sub can cause such a crash when one extra variable is included in an equation, which actually performs as it should, but then seems to cause problems exiting the sub?
Crashes of Access are not regular errors that you can fix by changing your VBA code. No matter what your code is, under no circumstances should this happen.
That said, from time to time Access does crash. Most of the time the cause lies in an inconsistent compilation state. That can be easily remedied by decompiling the database. Follow the instructions over here: https://stackoverflow.com/a/3266849/6216216
And make sure you have a backup copy of the database before you decompile.

Report Viewer error occurring occasionally

My problem is about report viewer, I didn't know what is the cause of this problem. And it is only occurring occasionally. The problem says something like
Local Report Processing
-----------------------------------
...The process access the file path path\expresion_host_5bc339f79dc24f2fb4b34667e9fadb13.dll
because it is being used by another process
(sorry for not providing complete details, or image, they just chat me this)
but it didn't run, after close the form, i dispose the reportviewer and form, and if re-open it and do it many times, this error will show. And i'm freaking here to solve this, i tried to google it first but none of them help me with this.
by the way, in my workspace, this error is not showing.
but in my boss, this error is showing, maybe because he is using Windows 8.
1.) Application Run As Administrator
2.) When you Close Application at that time use Application.exit at end of code
When a report ( printing ) function is run, a dll ( it is a working temp file generated by application to set a parameter etc.. ) is created in a temp folder for a millisecond and deleted.
At that time if the new antivirus program is catch the file, it also checks and release. and it is locked while it is being checked and your application dump ( the error message ) at that time.
So remove your anti virus you will see problem will be solved. Stopping anti virus may not enough. AV services continue to check every file and blockes.

Word VBA unhandled error not displaying a message

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.