to refer to module in external db

[.]

Set oAccess = CreateObject("Access.Application")

With oAccess
.OpenCurrentDatabase sOldDB
.DoCmd.DeleteObject acModule, "AAA"
End With
oAccess.Quit

Although not a reference to module in a *non-current* db,
I do not complain because deletion stopped Access' crashing,
allowing the things that I had been trying (incl DoCmd.CopyObject)
to proceed.

Everybody, we raise TC onto our shoulders for a hero's ride.

 

[.]

Set oAccess = CreateObject("Access.Application")

With oAccess
.OpenCurrentDatabase sOldDB
.DoCmd.DeleteObject acModule, "AAA"
End With
oAccess.Quit

Although not a reference to module in a *non-current* db,
I do not complain because deletion stopped Access' crashing,
allowing the things that I had been trying (incl DoCmd.CopyObject)
to proceed.

Everybody, we raise TC onto our shoulders for a hero's ride.

 

[TC]

Although not a reference to module in external db,
I do not complain, because deletion stopped Access' crashing,
allowing the things that I had been trying (incl DoCmd.CopyObject)
to proceed.

Everybody, we raise TC onto our shoulders for a hero's ride.

Blush!

TC

 

[TC]

Excellent TC, great code as usual.

Thanks for the compliment

Just one question, could this be applied
in a secure environment, such as a secure OLD.MDB?

Good question. I'm not sure. Certainly a non-secured database can access the

data< in a secured database, if it has access to the workgroup file, &

knows the username/password of a suitable user. The non-secured database
uses the PrivDBEngine object to start another session of Jet, passing it the
workgroup file, username & password to use for that session.

However, that wouldn't let you add or delete modules. The modules are
visible as documents in the Modules container of the Jet workspace, but they
are strictly read-only there. You would have to start another session of
Access, so you could do the DeleteObject. But I'm not sure how you'd get
that session of Access to use the relevant workgroup file & user. Perhaps
I'm missing something obvious?

What might the connection code look like for that?

This technique seems to be similar to that employed in the App 'Surgical
Strike' touted a couple of years ago as an Access auto update / patch tool,
but that app couldn't cope with secure environments so it seems to have
slipped below the surface - maybe its still around?

I don't know that app. But the restriction you mention, might suggest that
the problem is insoluble.

HTH,
TC