When I reached the point in the development of my most recent project where I was about ready to deploy it, I began to think about the process of actually deploying this new application and began to wonder about what issues I might encounter when I did deploy it. I knew that I was going to be deploying this new application to users that would most likely not even have Microsoft Office installed on their computer, much less have MS Access 2010. So there was really no decision to be made. I had to deploy the application and install the runtime version of MS Access 2010.
As I began to research the deployment of the runtime version it became increasingly clear that I could expect to run into some issues. I was reading postings by some developers who had not been able to get their application to run under certain circumstances. There seemed to be more issues when deploying the Access 2010 runtime version to users with a Windows XP machine. With this in mind, I decided to start my deployment efforts on an XP machine that I had sitting around. Actually, to tell the truth, I have been developing the entire application on an XP desktop machine and a Windows 7 laptop, but I actually did have another XP machine that I could use to test my deployment efforts.
Please note that this XP machine had had MS Office 97, including MS Access installed on it. I first decided that I would un-install the Office 97, including MS Access. I then downloaded and installed the Access 2010 runtime version. I also created an entry in the registry to create the needed “Trusted Location” as per the instructions that can be found here: http://www.accessribbon.de/en/?Trust_Center:Trusted_Locations as well as other locations. I then started my test of running my application by first attempting to run the .accdb file using the Access runtime version. I immediately got the message shown below.
After receiving this message, the application immediately shut down. No other information was available about the cause of the error.
My next effort was to rename the accdb extention to “accdr”. When I attempted to run my application using this renamed extension I received the error message shown below.
This error was actually from the error checking in my application and indicated that there was an error in the VBA code in the Form_Unload event of a form named “frmHidden”.
Let me stop here and explain that I had tested my application extensively and had included error checking at every appropriate place. Opening my application and running it on both XP and Windows 7 machines to be sure there were no errors, especially when just opening the application.
Next on my list for testing was to have Access compile and create an accde version of my application. When I tested my new complied version of my application on my test deployment XP machine, I was able to login to the application and I was thinking, “Ok, now I have it working.” As I reached a critical place in the usage of the application I again received an error message very much like the one shown above with the exception that it referenced code behind a totally different form. Due to the fact that I was so confident that I did not have problems with my VBA code that would cause this kind of error, I was hesitant to even look at the VBA code. After doing a lot of searching for answers and finally even looking at my VBA code, I was even more confused about why my application would not work when being deployed on an XP machine. By the way, perhaps I need to say right here that during this same time I was doing some testing of deploying the same application on a Windows 7 machine and was not experiencing any issues. I also was not getting any of the errors that I was seeing on the XP machine.
Needless to say, this was very frustrating and there was not a lot of assistance or help available. In fact, some comments I read had me just about ready to tell my users that they would not be able to use my application on their Windows XP machine but would have to upgrade to Windows 7 if they wanted to run my new application. My better judgment told me this was not the correct option.
Just to provide some information about my application, please understand that I had never before created an entire application that was linked to an SQL Server database. I have really had a severe leaning curve going on and I have come to have an even greater appreciation for using stored procedures and pass-through queries.
While all of this was going on, I was also thinking about changing the way I was accessing some data in a few strategic places the application, so I decide to take a break from the deployment issues and work on implementing the use of a pass-through query to replace the use of a DAO record set to return a small amount of required information. Although the DAO record set did not seem to be extremely slow, it was just interesting to me how much better the response was when I used a stored procedure or a pass-through query than when using the normal record set method.
Hang around for another day or so and I will share what happened with I changed from using the DAO record set method to the pass-through query method.
I will be posting the results of this change in my next blog posting.