VBA Code not executed on one particular form. Why? (long) 2

[JimPDX]

Greetings.

I have an unusual VBA problem within the Access 2000 application that my team and I have created. Let me first explain the app and environment: we have created a multi-user (not client/server) app that is starting to be used in multiple offices, each office having a Windows NT server and workstations running W2K. Each workstation in each office has an Access 2000 .MDE “local” program that links to tables in an .MDB “server” file on their server. As you would expect, the .MDB “server” file on the server contains only tables, while the “local” .MDE file on the workstation contains VBA code, form definitions, report definitions and some temporary tables.

Now the problem: One of the offices described an unusual error while running the app from a workstation. Whenever they clicked on a command to take them to form X, the form would display in a window but unusual errors appeared, and none of the features or commands on that form functioned at all (I’ll explain more error details later). We tried recreating the errors in our development and test environment using the same .MDE file they were using and then tried with newer .MDE files, but could not intentionally recreate it. We continued creating newer updated versions of the “local” .MDE file to distribute to the offices to use (wit other bug fixes), and one day found an .MDE we created a short time ago that had the error. This time, however, every office and test environment that uses this particular .MDE shows the errors. (Unfortunately, we do not know of anything different when that .MDE was created from the other times we’ve created them.) But just yesterday, we created a new .MDE, tested it, it seemed to work okay, then sent it to some offices, and one (but not all) of them reported the error. This newest version does not show the errors in our test environment, and at no times has the error appeared when using the .MDB version of the “local” file (the one we use to create the .MDE) in our test environment. Strange, huh?

So here’s some more details on the errors that happen when using the .MDE that causes the errors. The app launches and loads normally. From the main form that appears a user can click a button to display form X. The form will display in a window, but none of the VBA code that should run when the form is loaded [in Sub Form_Load()] gets executed. Also, once the form is displayed and the user does something with a control, any of the VBA code that should run (i.e., is attached to an event for the control the user manipulates) is not executed. Instead the following error is displayed:

“Object or class does not support the set of events.”

These errors only happen on form X, and once the form is closed, the rest of the app seems to function normally.

We’re a bit baffled as to how or why the form gets messed up and does not execute the VBA code. Again, we’ve only noticed this problem in only certain instances of an .MDE that we created, never in the .MDB that is used to create the .MDE.

Does anyone have any idea what might be going on here????

Thank you!

Jim.

 

[mikeyb540]

It appears that your test environment has more components or Office SP fixes then the users.

The basics checks would be the Service Packs for ms-office.
Just for testing just try the MDB on of the users pcs and check the form's Refrences, there might be something missing.

What OS is on the user PC?
What code do you have on that form?

Hope this helps

 

[vbajock]

Super weird. I had funny things like that happen and it seemed to happen when we compiled the MDE on an NTFS partition and then copied the MDE to a FAT disk. Drove us nuts for a while. When we finally caught on we converted all local disks to NTFS and end of problems. You might want to do a controlled test of that as a possibility.

 

[JimPDX]

Thanks for your ideas. Here’s some responses to your responses:

We don’t use any FAT partitions in either our workstations or servers, and our test environment (server and a workstation) is the same as the offices that are using the app.

The OS on the users PCs is Windows 2000 – same as our test environment.

Regarding the code behind the form… When the form loads, it’s supposed to look in a folder on the server, get a list of file names (image files), store these file names in a table and display the file names in a list control. After loading, the user can click on a file name in the list, and the image file is opened and displayed in another control. Once selected, there are other controls that the user can select on the form with VBA code to move the image file to a different folder on the server and do a few other things, but this code never gets executed – we keep getting that error message that I mentioned earlier. We use an Atalasoft ActiveX control for displaying the image. At first I thought the error had something to do with this ActiveX control, but we use the same control in another form in the app and there has never been a problem with it.

Any other ideas?

 

[vbajock]

I got to vote with the Service Pack issue. Have you ascertained that all machines are at the same level?

 

[KornGeek]

Just going back to standard debugging procedures:

1) What are the differences between this form and other forms? Look at as many factors as you can think to check. This includes the data source, any initialization code, etc.

2) What are the differences between the machines that work and those that fail? Again, look at as many factors as possible. This would include hard drive space, memory, processor speed, OS and SP versions, dll files, etc.

3) What line of code is failing? My favorite method for determining this is to create a text box, and change the value in it using code. Then, based on the value in the text box, you can see where your code is failing. After you are done debugging, you can either remove this text box and the corresponding code, or simply make it not visible.

4) What other differences exist? Could it have something to do with how the users interact with the system? Sometimes small differences in user actions can cause significant differences in results. If possible, try switching a user from a machine that works with one from a machine that fails. See if the problem follows the machine or the user.

In general, try to isolate what is causing the problem, then you can try to solve it.

 

[mikeyb540]

As I mentioned and VBAjock agrees check the Office SPs on the users.

One thing that I have also encountered is the connection to the server. If they are saving the image to the server using a drive mapping, sometimes the connection has timed out.
Check if the drive mapping has a X (Disconnected) in Windows Explorer.

I strongly recommend you use UNC in your code to the server \\SERVERNAME\SHARE
Also, just for the sake of testing use the MDB on one of the user's PCs.
Did you check the Refrences on the Form?
1. Highlight the form that has the issue
2. Go to View - Code
3. Tools - Refrences

Check if any of the checked components are missing something. You might want to compare it with the original.
Just remember to use the MDB. Once this is resolved compile the MDE.

Let me know if that makes sense.

 

[vbajock]

mikeyb may be on to something. We had a job once where Dlink cards caused a problem with graphic files due an issue with the card BIOS or driver. You might want to check for a commonality in that area. The MDB thinks everything is ok, because a bug in the network software fails to send it the low level flag that indicates a timeout has occurred, hence no error message, and no data because the server timed it out. Are you running at 10, 100 or 1000 mips? 10 and early 100 mip cards from cheapo vendors had this problem.

One other technique, if you run DIR *.dll >Dir.txt in the Windows System directory on the clients you can import the resulting txt file into a mdb table on the local machine, and then attach the tables to a master database and compare DLL dates. This might help you pinpoint a subtle difference somewhere in DLL versions.

 

[KornGeek]

vbajock,
I like your idea for checking the dll versions. That's very creative. I'll have to file that one away for future use. Thanks.

 

[vbajock]

It's a great technique - you can also code it into your project, include an internal table containing proper DLL dates from your Dev machine, and it can check for DLL problems at the client on initial start up, finding missing or out of date DLL's. A must have if you are working on large networks with 98, 2000 machines.