Results 1 to 3 of 3
  1. #1
    5 Star Lounger
    Join Date
    Jan 2001
    Location
    Vancouver, Br. Columbia, Canada
    Posts
    632
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Reference conundrum (A2002, A2003)

    Developing a database on my office computer (A2002) that is primarily for my own use. However, a few other people in the office will likely use it, and it may be distributed to a few select sites outside the office. Therefore I am making my first attempt at using an Installer product to create an installation package (Using Installer2Go - http://dev4pc.com/installer2go.html). The application uses two third-party libraries. That's where I am having some problems, and I am seeking advice about whether I am on the right or wrong track.

    The target computer for the first installation of the setup package was on my home computer (A2003). Upon opening the MDB file, I found that one of the libraries was properly referenced, but that the second library referenced the location on the development computer, NOT the location specified by the setup package. I know I could change the location of the library on the development computer to match the intended distribution location, but I reasoned that if the installer package *allowed* different locations, it should be feasible to do so... The library is on the D: drive on the development machine, but I wanted to put it onto C: on the installation package.

    The DLL file was in the D:AppChilkat Software IncChilkat XML ActiveX folder on the development computer.
    The setup package allowed me to specify *that* folder as the source for the installation package.
    The setup package allowed me to place the folder in C:Program FilesCommon Files on the target computer.
    The file was installed to C: on the target computer.
    The setup package allowed me to "self-register" the DLL
    The MDB file retained the invalid referece the the D:App location.

    My questions are about *how* Access references the libraries:

    Does Access use a symbolic representation of the library (e.g., "MyLibrary"), and then resolve it to the actual location on the target computer, or does Access "hard-wire" the file location of the development machine, and expect to see that specfied file on the target machine?

    Does this behaviour depend on the particular library -- in other words, are some libraries portable by design, and other must be hardwired in Access?

    Or does it depend on *how* it's installed on the development computer in the first place? Maybe I did something to hardwire the file into Access instead of allowing a symbolic representation. I've always been a bit confused over why some libraries automatically appear in the list of References, while others need to be browsed-for. I *may* have browsed for the library on the development computer -- can't recall the details.

    Are there standard practices to use in order to ensure that references will be intact on the target computer?

    Should I just bite the bullet and move the files on the development computer into the intended destination folder? Any suggestions for online references that I could read about this topic?
    --------------------------------------------------
    Jack MacDonald
    Vancouver, Canada

  2. #2
    Super Moderator
    Join Date
    Aug 2001
    Location
    Evergreen, CO, USA
    Posts
    6,623
    Thanks
    3
    Thanked 60 Times in 60 Posts

    Re: Reference conundrum (A2002, A2003)

    I checked with my resident guru on the subject, and he offered this:

    If you are referending a DLL, OCX or whatever that is registered at the system level, then you may not need the Access reference at all - it apparently depends on the object and whether it supports early or late binding. You can test this sort of thing by unchecking the reference on the development PC, and then checking to see if it still works. A good number of the commercial products don't need to be referecned in Access if they are registered on the system.

    If on the other hand, the object needs an Access reference, then you will probably need to change the reference on the target install system. One trick we use is to put the library files in the same folder as the application MDB. You might also find About how Access searches for reference libraries helpful in understanding the search process that Access uses.
    Wendell

  3. #3
    5 Star Lounger
    Join Date
    Jan 2001
    Location
    Vancouver, Br. Columbia, Canada
    Posts
    632
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Reference conundrum (A2002, A2003)

    Thanks Wendell. Your suggestion about the application-folder installation, and the background info from the article were very helpful. I will install the DLL into the application folder as you suggested.

    FWIW, here's what I did, and the results at each stage.

    - on a "clean install" computer -- it had never seen my Setup before BUT it did have a system-level installation of the DLL. I created a brand-new MDB file, and checked the References. The DLL was listed in the Reference list, and it was pointing to the "system-level" folder. IOW - it was what I expected to see with a "vendor-supplied" installation of the DLL

    - ran my Setup program -- the setup copied the DLL into the Common Files area, as expected. The application continued to work properly. Checked the References, and it continued to point to the system-level folder. IOW, my Setup program had no effect on the system-level installation.

    - using Control Panel > Add/Remove programs, I removed the system-level reference to the DLL. Cleaned up the CommonFiles folder.

    - Ran the setup program again, but this time, setup used a "Repair" dialog (my MDB program was still installed). Setup restored the files in the CommonFiles folder. Opened my MDB, but it failed with a Missing Reference error. Checked the References, and it was pointing to the folder from the Development machine. IOW, the Setup program *did* copy the DLL to its "correct" location, but the MDB could not find it even though the Setup program purported to register the DLL with Windows.

    - using Explorer, I copied the DLL into the same folder as the MDB. This time it worked properly, and the References list showed the location correctly ie, in the same folder as the MDB.


    Conclusion: if the DLL is properly referenced at the system level, then it will continue to be used from *that* location. If it is not registered at the system level, then installing it into the same folder as the application will be sufficient for Access to find it. I haven't tested yet, but I suspect that configuring the Setup program to copy the DLL to the application folder, without making any attempt to register it with Windows, will be sufficient.

    FWICS, the only pitfall for this strategy is if the target computer has a system-level reference to an outdated version of the DLL. In that case, the MDB will continue to use the old version, rather than any new version that the Setup installs. It's not an issue with this particular project, but might be important in some other circumstances. I guess this is what is meant by DLL Hell.


    Thanks again.

    ================================
    I should know better than to post before testing. Copying the DLL to the application folder without making an effort to register it is insufficient. MDB failed to run properly, even though the Reference list indicated that the file was not Missing.

    So I tried the Setup program's "autoregister" configuration. This time there was a message that the DLL did not support that feature. Was finally able to make it work by running Regsvr32 at the end of the setup program.
    --------------------------------------------------
    Jack MacDonald
    Vancouver, Canada

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •