Refreshing Referenced Module

[Axel]

HI

I want to reference code in an external Access Database, and refresh
that database (by downloading from network location). Do I need to
bootstrap? Or is it possible (during autorun) overwriting the
referenced database?

Currently the Customer uses one shared referenced Access Database
(which is about 80 MB) which is impossible to update because its
referenced to a network path from around 25 to 30 users. I want to
break out the shared code into smaller units and copy them down to the
local hard drives. I also want the Referencing Database to check the
version number of the referenced module on start up and force to
overwrite the mdb with the newer versions from the network.

I have already done something similar in VB where I wrote a bootstrap
app that downloaded the new version and then restarted the App, (kind
of like ping pong) question is do I need to employ the same technique
with Access or is it possible (during startup) to replace the
referenced module?

thanks in advance
Axel

[Arno R]

You may need something like:

Dim ref As Reference
Set ref = Application.Ref erences!YourRef erenceLib
Application.Ref erences.Remove ref
'--->> ChangeFileHere or do whatever ...
AddRefAgain:
Application.Ref erences.AddFrom File "FullPathToYour ReferenceLibHer e"
SysCmd 504, 16483 ' - Save And Compile
Debug.Print "CompileVal ue: " & Application.IsC ompiled

Arno R
"Axel" <re***********@ hotmail.com> schreef in bericht news:11******** *************@y 43g2000cwc.goog legroups.com...

HI

I want to reference code in an external Access Database, and refresh
that database (by downloading from network location). Do I need to
bootstrap? Or is it possible (during autorun) overwriting the
referenced database?

Currently the Customer uses one shared referenced Access Database
(which is about 80 MB) which is impossible to update because its
referenced to a network path from around 25 to 30 users. I want to
break out the shared code into smaller units and copy them down to the
local hard drives. I also want the Referencing Database to check the
version number of the referenced module on start up and force to
overwrite the mdb with the newer versions from the network.

I have already done something similar in VB where I wrote a bootstrap
app that downloaded the new version and then restarted the App, (kind
of like ping pong) question is do I need to employ the same technique
with Access or is it possible (during startup) to replace the
referenced module?

thanks in advance
Axel

[wannall]

Thereis no technique you can use to replace an in-use Access mdb.

If your people will be using them locally, you can copy the new bits down
before you open any of them. I still do this with VB (well, VB.NET now) as
a front-end to my access app. The little version checker/copier is so small
that the overhead is negligible, considering the version stay up to date
constantly, and it's capable of checking and copying only exactly what's
needed.

Not to mention that using a vb or vb.net app ahead of the access pieces
opens up all kinds of other possibilities about how you can respond to
command lines.

[Axel]

the front end is probably the best way, but hard to enforce as the app
runs in three plants. (3 Bosses and close to 50 users to convince) -
they are not used to tight version control although the original author
(he is one of the bosses) constantly potters with the frontend.

They might simply refuse to run it. So better if I could invoke this
app in Access.autorun and close down / restart (which is effecitvely
like bootstrapping). Of course I could take the lazy route and just
deny access + point to a batch file: "Your app is out of date, please
run RefreshDB!" - admittedly the cheapest way out.

thanks
Axel

wa*****@sbcglob al.net wrote:

Thereis no technique you can use to replace an in-use Access mdb.

If your people will be using them locally, you can copy the new bits down
before you open any of them. I still do this with VB (well, VB.NET now) as
a front-end to my access app. The little version checker/copier is so small
that the overhead is negligible, considering the version stay up to date
constantly, and it's capable of checking and copying only exactly what's
needed.

Not to mention that using a vb or vb.net app ahead of the access pieces
opens up all kinds of other possibilities about how you can respond to
command lines.