Re: Opening report in another db
- From: "dpcman01" <bob@xxxxxxxxxxxxx>
- Date: Sat, 4 Oct 2008 08:43:03 +1000
"Sky" <s.young @ stanley associates . com> wrote in message
news:gFqFk.401$yI6.198@xxxxxxxxxxxxxxxxxxxxxxx
Steve,Steve,Do you have any ideas to overcome this reference addressing issue?
--
Bob Darlington
Brisbane
If you install the referenced library database .mde file in the same
folder as the front-end application .mde, then the front-end will find
and reference the library database automatically, even if it was
compiled in a different path on the developer's computer. I have used
this feature in both Access 2000 and 2003. I would expect it works the
same way in Access 2002.
Another option is to create the RefLibPaths registry entry, but that has
proved more troublesome for me, especially if you install more than one
application on the same customer computer.
- Steve
I followed your advice and loaded the referenced mde in the same folder
as the front end mde, but get an error message indicating that there is a
missing reference (ie "The expression you entered has a function that ...
can't find" .
If I load the front end as an mdb, there's no problem, but my distributed
app needs to be an mde.
I might need to look at your second suggestion with RefLibPaths, but here
again, couldn't I expect to have the same problem from an mde front end?
One thing to check is that the compiled front-end .mde should not find any
obsolete compiled library .mde or uncompiled library .mdb in the original
referenced path or in any another search location, because it might find
that first and complain about the reference. Make sure that on the target
customer runtime installation that only the correctly matching compiled
library file can be found.
The front-end compiled database .mde must find the EXACT matching library
.mde that the front-end was originally referenced to and compiled with,
and it must be FIRST in the path search order. It is very sensitive to
this. Whenever you recompile the library, you must ALSO reference and
recompile the front end.
Here is Microsoft's explanation of the search order to resolve the
reference, for all versions of Access:
http://support.microsoft.com/kb/824255
(Note: I automate this process by first compiling my uncompiled library
.mdb to an obscure temporary file path for a uniquely named library .mde,
then copying the front-end to a new .mdb file, temporarily relinking this
front-end copy .mdb to the obscure library .mde, and finally compiling the
copied/relinked front-end to its .mde. The compiled .mde front end and
obscure library file .mde are both installed at the customer in the same
folder, using the InnoSetup packager in my case. The customers do not have
the obscure path on their computers, so the library .mde is found only in
the same folder and it matches correctly.)
Using the same folder, or using RefLibPaths, has never failed to resolve
the reference in my experience, using compiled front-end and library .mde
files, EXCEPT when the compiled front-end found an incorrect matching
library name somewhere else first, or failed to find any match.. By
"incorrect", I mean a matching library file name that was not the EXACT
SAME library .mde file that the front-end was originally compiled with.
The Access references are very sensitive to finding an exact match to the
files it was originally compiled with.
In the old days, I did use the RefLibPaths registry setup successfully.
However, the RefLibPaths naming convention is poorly designed and permits
only one library file with the same name on a single computer. This is a
problem if you want to deploy two different library versions (with the
same name) with two different applications at different times. If you ever
recompile the library, you must also recompile the front-end, and any
other compiled front-end that looks for the same location has the error
you encountered. I was able to get around this easily by renaming the
compiled library to a unique application-specific name, and I still do
this, but now the same-folder method seems easier than RefLibPaths.
Microsoft certainly made it difficult to distribute a library database of
reusable tools and forms that you can use in your applications, but once
you have it down it does work consistently.
- Steve
Thanks for taking the time with the detailed answer.
What you say makes sense, and I'll give it a run tomorrow.
--
Bob Darlington
Brisbane
.
- References:
- Opening report in another db
- From: dpcman01
- Re: Opening report in another db
- From: dpcman01
- Re: Opening report in another db
- From: lyle fairfield
- Re: Opening report in another db
- From: dpcman01
- Re: Opening report in another db
- From: dpcman01
- Opening report in another db
- Prev by Date: Shifting back colors on combo boxes
- Next by Date: Re: LED light simulation (circle)
- Previous by thread: Re: Opening report in another db
- Next by thread: Combining Tables
- Index(es):
Relevant Pages
|
Loading
