Late binding with the VBA or Access libraries

[Chris]

Hi

I have read most of the threads on late binding issues, with great interest
and have found them extremely useful. Symptoms discussed and described here
sound just like a problem I currently have.

I have modified my code to remove as many references as possible (which I
suspect were the cause of my problem) and now have only 3 references. These
are for the VBA, Access and DAO libraries. I know that the target machine has
the same path names as for two of these (the DAO and VBA ones), but not for
the Access library.

I am deploying my solution to the client machine via the packaging solution,
and bundling up the Access runtime files.

My question is this: Do I need to worry about the Access reference not being
there (as I suspect it wouldn't be if a target machine has not got Access
installed) as it will be (somehow) resolved during the installation, or at
runtime (is this the case also with the VBA library if it did not exist on
the target machine)?

If it is the case that this will be resolved without me having to do
anything, I would welcome an explanation as to how this happens in the
backgound as I am clear about the thinking behind use of other libraries, but
now this

Any feedback would be most welcome

Thanks
Chris

 

[Douglas J Steele]

The runtime should provide the necessary library files for you. When you
install the runtime, it installs whatever other supporting files it
requires, and all 3 of the libraries you list are required by Access.

 

[Chris]

That is what I hoped would happen, but I still do not quite understand the
VBA library reference.

As there is no C:\program files\Microsoft Office\2003 library after
installation - where my development copy has a reference to for the VBA -
where will this point to when I install the runtime on another machine?
Should I expect to see this library created?

Regards
Chris

 

[Douglas J Steele]

To be honest, I'm not actually that familiar with where the runtime puts its
files.

You could try doing a search for MSACC11.OLB after the installation, just to
see that it's there.

I believe that Access is actually using the GUID in the registry to resolve
the reference, rather than the specific file location.

 

[Chris]

Hi

Just a quick update to complete this thread. I re-installed my system with
just thee three references as decribed earlier. This has resolved my problem,
and I no longer get broken references (which in my case were maifesting
themselves as problems with the format$ function). So the runtime clearly
handles these in the backround.

Thanks for your help and input

Regards
Chris