Why on some, not on others?

[tekno]

I have developed a front and back end program for a client with a 10 computer network. The front end is well proven to work. One routine, to select one record from a pick list, click and run a macro that opens a form with a query filter, now does not work on one of the networks computers, and for some strange reason, does not work on mine, the one that is off of the network and the one on which the program was developed. It works on all other computers. Any thoughts?

 

[Pat Hartman]

It is most likely a reference problem. On each machine where the db fails, open any code module and then select Tools/References. Fix the missing reference. First try unchecking the reference then close and open the db. If it still doesn't work, you'll need to install the missing library.

 

[tekno]

How do I know what the missing reference is? I see the first four in the list that are checked, but I do not know which one is the one in question.

 

[Pat Hartman]

If nothing is marked MISSING, try finding Microsoft DAO 3.6 or 4.0 item in the list and checking it. Then save and reopen the db. The point is to force Access to refresh its reference collection.

 

[tekno]

OK Pat, on this reference issue, I just received information from my client that the computers on which the aforementioned problem occur are not running Windows 2000, the OS that is on the data server. Could this be a problem when running apps written in Access 2000? And yet another problem has been reported. When this computer is turned off, and rebooted, the tables in this program need to be relinked.

 

[Pat Hartman]

I can shed some light on what breaks the references. Access works somewhat differently from other products in that it doesn't implicitly "believe" the ActiveX contract that newer versions of a .dll will not break apps created with an earlier version of the .dll. Consequently, Access keeps track of the library's path and object id as they are on the system where the db was created. Therefore, moving an Access db to another computer that is running a different version of windows can "break" the references either because the .dll is stored in a different path or because the .dll is a different version. The references can also "break" on the system where the db was actually developed. This can happen if you install a new version of windows or if you install some other seemingly unrelated product that happens to install a different (hopefully newer although there are still many bad apps that just replace new .dll's with old without even asking) version of a .dll your app is using.

There are articles in the Microsoft knowledge base that talk about this problem and offer code solutions that sort of work.

I have not seen your second problem but I would guess it has something to do with how drives are mapped in your environment. You can probably overcome this problem by changing how you link the files originally. Rather than choosing a hard-mapped drive letter, use the UNC naming convention. Open the link table manager. Check the box that says prompt for new location. When you get the common file dialog, rather than choosing a drive and a directory, just type the UNC path into the file name field. \\ServerName\full path\Yourdb.mdb

 

[tekno]

Thank you Pat. That does make sense to me. I am going to get on my client's network, which is another city, this weekend and do just as you wrote. I do not know exactly what the new or different additions were/is but I suspect some Office 2000 or Windows Update that I did a few weeks ago. I will let you know how it all goes down. Steve (tekno)