Missing references that aren't

[Peter Whittaker]

Access 2000 .mdb stored on shared drive on 2000 server
with multiple users running the app from their Win98
workations. DB is not split due to performance issues when
it is.
Whenever I make changes and copy the file back to the
server some users only get a "Can't find project or
library" error and the JRO dll is reported as missing even
though the correct dll is in the reported location.
I have tried all the 'global' fixes in the MS KB e.g.
creating other copies of the dll in appropriate locations
but THE ONLY WAY I can find to fix this is to re-build the
reference from within the app on the workstations where
the problem occurs.
That is a complete pain especially since you need to be
the sole user to re-build a reference.
Interestingly the problem does not occur with XP which
seems to create copies of the dll on the fly at run time.
Has anyone else had this problem? Anyone found a solution?

Thanks
Peter

 

[TC]

Access 2000 .mdb stored on shared drive on 2000 server
with multiple users running the app from their Win98
workations. DB is not split due to performance issues when
it is.

There are simple fixes to this well-known problem. You should consider going
back to a FE/BE structure & adding those fixes. One of them is to open a
permanent reference to the BE database, using Dbengine.Opendatabase(). Hold
that reference open for the duration of the FE session (ie. make it global,
or static).

Whenever I make changes and copy the file back to the
server some users only get a "Can't find project or
library" error and the JRO dll is reported as missing even
though the correct dll is in the reported location.
I have tried all the 'global' fixes in the MS KB e.g.
creating other copies of the dll in appropriate locations
but THE ONLY WAY I can find to fix this is to re-build the
reference from within the app on the workstations where
the problem occurs.

If a referenced object is in a different location on a user's PC, that will
break the reference, and cause various problems. You >can< code for this, so
the application will invisibly detect - and mend - the broken reference; and
this works even in an MDE. But the method isn't simple. Check out
www.trigeminal.com for some starting information.

That is a complete pain especially since you need to be
the sole user to re-build a reference.
Interestingly the problem does not occur with XP which
seems to create copies of the dll on the fly at run time.
Has anyone else had this problem? Anyone found a solution?

I can't imagine that any copy of Windows creates temporary copies of DLLs at
runtime for that purpose!