I have an Microsoft Access 2010 database application with split front end and backend which has started to behave oddly, and I've exhausted all the options I know for investigating and resolving the problem.
32-bit Access 2010 running on Windows 8.1... I have both Access 2010 and Access 2013 installed, but the problem also manifests itself on a Windows 8.1 system with a completely fresh install of Access 2010 and no Office 2013 present. The issue also exists if the application is run using Access 2010 Runtime. The front-end is running on my hard disk, not in a Dropbox or similar environment. The back-end is in Dropbox.
There are a couple of third-party elements in the application -- references are as shown -- example 1 on the system with both Access 2010 and 2013 present, example 2 on the system with just Access 2010 present.
There hasn't been a software update to the Treeview control since December 2013. I've checked that the versions of the third-party controls I'm using are compatible with Windows 8.1.
Symptoms:
The application (an unreleased development version) initially works perfectly, but if closed and reopened, one specific operation (right-click on a third party treeview ActiveX control on the main form) misbehaves -- the right-click event is triggered multiple times instead of just once (the number of times is unpredictable). There are two treeviews on the main form with identical settings (populated dynamically with different data sets). One treeview behaves, one doesn't. Even if I remove all code from the right-click event, it fires twice.
This main form configuration and code hasn't been changed in over one year, not has the treeview config or code. I don't use Compact on Close. The application isn't logging any errors.
What I've tried:
If I restore a previous version of the application, it works... and when reopened, doesn't work. (I've tried this with several previous versions of the database.)
I've tried importing a copy of the main form from an old working version of the database -- same problem.
I've tried deleting the malfunctioning treeview and creating a new one (copying the one that is working) -- same problem.
I've tried creating a new blank database and importing all the objects from the old one. Once I've restored the references manually, the same problem.
I've reviewed all the possibilities mentioned in Can't eliminate Access corruption -- one commonality I have with this question is that I've (last three months) started using the VBA Implements keyword, but I hadn't made any changes to this code immediately before the problem showed up, and neither the main form nor the treeview control utilise it.
I've emailed the support team for the treeview control, but they haven't anything to suggest that I haven't already tried.
I've repaired the installation of both Access 2010 and Office 365 in case the references were somehow messed up.
I've un-installed Office 365 and Access 2010, rebooted the machine and reinstalled Access 2010. The references are all Office 14 references and the problem still exists (in a compiled accde). As soon as I reinstall Office 365, the references become mixed 14 and 15. (This is also true for the working version which is two years old).
What I haven't tried yet:
Rolling back a two months' worth of Windows updates to see if it's a Windows issue (this system has only been in use since early September, so this wouldn't be hugely onerous to try).
Rolling back to a version of the app from December 2012 (the last production release) which doesn't seem to have suffered the corruption and manually reapply almost two years worth of development changes. This would be a mega undertaking....
Are there any other options for investigation or resolution that I can try?
Edited to add: What finally worked
I created a new empty database, imported everything from the old database except the main form, which I recreated from scratch to look identical and have the same code as the old one... And the problem has gone away. It not very satisfactory as a resolution, but it seems to confirm that there was a corruption somewhere.
One of the best ways to remove corruption in an Access database is to save the forms and reports to text using the undocumented SaveAsText function, delete the form and report objects, close the database, use the undocumented /decompile switch to decompile the database, compact/repair the database, then re-import all the objects using the undocumented LoadFromText function.
Usually the Access databases corruptions affect the VBA modules, less likely the table data. So hopefully you should be able to copy the data to a blank database, get the VBA code from a older backup (since the last source code update) and merging the two together. It should work!
It won't stay fixed unless you disable updates. And you can't disable updates because you will be compromising security.
Related
I have written a rather complex application in Microsoft Access. It is split into front end and back end files. To protect my code, I have compiled it and saved it as a runtime .accde file, which I then changed to an .accdr file to ensure it operated as a runtime. I have created two versions of the application: one for those with 32-bit Office installed and one for those with 64-bit office. I have used Inno Setup to package the application, the data file, and other files such as the icon file, the license file, etc., into an installable package, which works just fine.
Among my team of 27 beta testers of this application, so far 6 have downloaded it, and I have tested it on four of my own computers. On seven of these computers, the installation works perfectly and the application runs with no problems.
On the computers of three of my testers, when they try to run it, they get this error message:
The expression On Open you entered as the event property setting produced the following error: Bad file name or number.
* The expression may not result in the name of a macro, the name of a user-defined function, or [Event Procedure].
I'm pretty sure I know where the code is that's causing the problem, but cannot for the life of me figure out why the application crashes on those 2 computers but not on others.
The On Open event I suspect of causing the problem checks the linked tables, gets their connect string, then looks at the path for that string for the back end database. If it does not find it there, the procedure pops up a file selector dialog and instructs the user to find the data file, then it relinks all the tables.
If anyone could point me in the right direction to fixing this problem, I would be extremely grateful.
This is typically caused by a reference labelled as MISSING.
You have two (three) options:
Run the application on the offending machines with a full version of Access that lets you debug the code
Create a small test application that lists and verifies the references you use, and run this on the offending machines
Remove those two customers
Thanks to all the contributors here. Because of these folks and additional online research, the latest answer I can find is this:
This error occurs on a small percentage of computers on which the app is installed, and no one has yet figured out why, what causes it, or how to fix it. The workaround is to install the 2013 version of the Access runtime, as later versions will still cause the problem.
At least one of the offending computers is running the Click-to-Run version of Office. Still gathering information, but that's the status as of now.
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 am having serious problems with the Microsoft Windows Common Controls 6.0 SP6 library in Access. I have a number of scripts which were working fine before the weekend, but which fail lately on multiple different computers when they encounter the StrConv function. Here's a low-down on what's been going on:
Previously, all was working fine. On the afternoon of Friday the 20th (4 days ago), I began encountering some odd messages when I moused over a progress bar ActiveX control I had on one of my forms. This happened on the MouseMove, MouseDown, MouseUp and MouseClick events at least; the message reported was "The expression [MouseMove] you entered as the event property setting produced the following error: There was an error loading an ActiveX control on one of your forms or reports." I had registered none of the events mentioned on this control. Scripts in general were still working at this point.
Yesterday (after the weekend), I found that scripts I had written no longer worked. When encountering the StrConv function (which I was using to convert a string to uppercase), the VBA editor brought up an error message saying "Compile error: Can't find project or library." This function I'd imagine is quite a core part of the VBA language, but the only missing library I could find under Tools->References was "Microsoft Windows Common Controls 6.0 (SP6)". The missing file was listed as C:\Windows\system32\MSCOMCTL.OCX but this was present on the machine anyway. Browsing to it in the references dialogue made no difference.
Since then I have tried installing various different Microsoft Visual Basic redistributions, have followed the instructions at http://www.fmsinc.com/MicrosoftAccess/controls/mscomctl/, have phoned our company's tech support and have tried a system restore to a point where the scripts functioned previously, but nothing has worked. The database I am using resides in a networked folder on a server but the MS Access applications are local to the workstations.
Is there any way to resolve this issue?
Simply open one of the forms giving you trouble in Design View. Insert a new ActiveX object control in the form and save. Load the forms again. Hopefully this solves the problem. You can then safely delete the added control.
I have an app in VBA consisting of many reports, queries, forms and tables. This .mdb file is linked to another .mdb file (the actual database for the app). This app was originally developed in Windows XP. But I have to move this app to run from a machine which has Windows 7. Now when I run a particular report in win 7 machine it throws an error.
The expression On Deactivate you entered as the event property setting produced the following error : A problem occurred while application was communicating with the OLE server or Active X component
When I comment out the Deactivate event from that particular report, the error is no more. But the interesting point is, when I use the same .mdb file to run from a XP machine, it works just fine.
I am very much confused. Any help will be highly appreciated.
Create a new report and, one by one, copy the controls from the previous report till the moment you get the error. The moment you got the error, discard that very control and recreate that very control again in the new report. After that copy the other remaining controls.
The idea is to pinpoint the control or controls which are causing the pain and then to discard those controls and recreate them again.
I have upgraded a 60 KLOC Windows VB.NET application to VS 2012 and Windows 8.
Everything looked fine, except when I deployed it yesterday to ClickOnce.
The ClickOnce application is incredibly slow to load every form the first time that form is launched, IF the form uses binding. If a form is not using binding (but selecting data from a DB query) they load normally.
The most funny part is that while debugging in VS2012 they load in less then 1 second. When launched from the ClickOnce version they spend more than 60 seconds to load.
If I close one of these forms in the ClickOnce application and re-open it, they load normally in less then 1 second.
It seems that Binding in VS2012 is very bad the first time a form is loaded, but I prefer to think I'm doing something wrong.
Any ideas about this issue?
EDIT 2013/01/18:
After one day cutting unnecessary code, I have arrived to a solution that reproduces the slowness and that has no unnecessary code, so that it will be easier (I hope) to find what is not working proprly in it.
ClickOnce application is here:
http://www.octet.it/Reproduce/
Source files are here:
http://www.octet.it/Reproduce/Reproduce.zip
I can state that slowness is NOT depending on:
SQL Server (I have cut all the code that was accessing SQL server DB).
Binding (there is no binding at all, now).
Development environment: if you run the application from VS2012 it works as expected.
Instruction for reproducing slowness:
Install the ClickOnce application on a Windows 8 machine (mine is
x64, I had not a x86 to test).
Start Task Manager.
Start the "Reproduce" application.
When the MDI form has loaded, hit [Return] key (this will fire a MDIChild form).
Have a look at task Manager, showing how the "Reproduce" app will saturate one of the CPUs of your
machine and occupy about 650 MB of your RAM.
After about 45-60 seconds a MDIChild form will appear.
Close the MDIChild form.
Hit [Return] again and see the MDIChild appearing almost istantly and Task Manager showing no CPU saturation or RAM increases
As I told, before Win 8 the MDIChild (with binding and SQL acces to various tables) appeared in about 2-3 seconds.
Source files are not so interesting to see: they will just show a MDIparent form calling a MDIChild form, but I have included them in the .ZIP file if you want to do some experiments.
MANY thanks in advance for your time.
Let me know what I can do to solve this problem. Any suggestions is welcome.
How are you compiling the application? Are you targeting mixed platforms? Try targeting x86. I had a similar issue that was resolved by targeting x86 when I compiled, which should work fine on your x64 box unless you have some crazy x64 dependencies in your application. Note that this will change the clickonce manifest, which is a headache, but I'm curious if this fixes your issue.