to refer to module in external db

  • Thread starter Thread starter .
  • Start date Start date
Set oAccess = CreateObject("Access.Application")
With oAccess
.OpenCurrentDatabase sOldDB
.DoCmd.DeleteObject acModule, "AAA"
End With
oAccess.Quit
Click to expand...

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
Click to expand...

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.
 
. .net> said:
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.
Click to expand...


Blush! :-)

TC
 
Excellent TC, great code as usual.
Click to expand...

Thanks for the compliment :-)

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

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, &
Click to expand...
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?
Click to expand...

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

HTH,
TC
 
Back
Top