Avoiding Broken References

Can you claim that you've never had a problem delivering an application to one of your users? Then you've probably never used references. Either that, or you are one of the fortunate developers who develops on a machine with a configuration that is identical to your users'. But even if the machine is identical, you can still run into problems if you have taken the time to develop a code library. You know what we mean — the one you forgot to take with you when you went to the user's machine to install your database.

Of course the first thing to do to avoid broken references is to be sure that you are delivering all of the components that go with your application. And don't forget those DLLs that you acquired from a vendor to improve the features in your application. And just delivering them isn't all that there is to it; you need to be sure you've installed those DLLs in the right folder and that they are registered properly.

So how do you know what the right folder is? When Access searches for referenced libraries, it first searches based on the file specification provided when the library was added. If the library is not found, it follows these steps:

1. Access searches for a RefLibPaths key in the following location in the Microsoft Windows Registry: HKEY_LOCAL_MACHINE\Software\Microsoft\Office\12.0\Access.

2. If the key exists, Access checks for the existence of a value name that matches the name of the referenced file. If it finds a matching value name, Access loads the reference from the path specified in the corresponding value data.

3. If Access doesn't find a RefLibPaths key, it searches for the referenced file in the following locations in order:

□ Application folder containing the application (the folder where Msaccess.exe is located).

□ System folders (the System and System32 folders located in the Windows or WINNT folder).

□ Windows or WINNT folder.

□ PATH environment variable. For more information about environment variables, see Windows Help.

□ The folder that contains the Access file, and any subfolders located in that folder.

If Access still can't find the reference after performing this search, you must fix the reference manually.

When running your code, classes from referenced libraries are not checked until the procedure that declares a variable using one of those classes is executed. In your start up procedure, you can walk through the References using the technique previously mentioned and use the isBroken property to find broken references. If you find a broken reference you can inform your user with a meaningful message instead of letting an error pop up from Visual Basic.

Was this article helpful?

0 0

Post a comment