Hi--
I am attempting to distribute a MS Access database with InstallShield Express X. I intend to distribute vbSendMail.dll with the database.
I can get InstallShield to drop the DLL into a "common" folder, such as c:\windows\system32 or the like, so that the Access database will not miss a beat when the MDB is installed wherever and it looks for the DLL in c:\windows\system32, where it was installed on my PC during development.
My exprience has been with broken references is that, whenever there is a broken reference, the database will act very erratically, such as stopping on very basic VB functions and giving error messages or compile errors.
In most cases, as long as the end user has installed windows on the C-drive, this should not be an issue. I just want to try and proactively make sure that my user that has windows installed on d:\windows\ isn't going to have to plow through the VB code window to manually clear the broken reference.
I have seen the code to clear a broken reference, and set a reference using VB code. However, when I implement this, it never seems to intercept the problem fast enough before phantom error messages start popping up.
Any advice?
----------
Jeff Wigal
Referee Assistant for MS Access
I am attempting to distribute a MS Access database with InstallShield Express X. I intend to distribute vbSendMail.dll with the database.
I can get InstallShield to drop the DLL into a "common" folder, such as c:\windows\system32 or the like, so that the Access database will not miss a beat when the MDB is installed wherever and it looks for the DLL in c:\windows\system32, where it was installed on my PC during development.
My exprience has been with broken references is that, whenever there is a broken reference, the database will act very erratically, such as stopping on very basic VB functions and giving error messages or compile errors.
In most cases, as long as the end user has installed windows on the C-drive, this should not be an issue. I just want to try and proactively make sure that my user that has windows installed on d:\windows\ isn't going to have to plow through the VB code window to manually clear the broken reference.
I have seen the code to clear a broken reference, and set a reference using VB code. However, when I implement this, it never seems to intercept the problem fast enough before phantom error messages start popping up.
Any advice?
----------
Jeff Wigal
Referee Assistant for MS Access