MDB referencing MDE Database

  • Thread starter Thread starter Gary
  • Start date Start date
G

Gary

I wish to have an open (mdb database without macros and modules) referencing
a mde database (with only modules or macros). The macros is option.

I have people who want the ability to do minor changes to reports (because
my turn-around time is 24 hrs or less). I was thinking of having an mdb
database that they can do changes and its reference all my modules (VBA Code)
in another mde database. I don't want people to see my VBA Code. I believe
with special tools, one can still see the code.

Someone indicated that my mde modules may need changes like Set db =
CurrentDB(), etc.

I would appreciate any suggestions on this.

Thanks,

Gary
 
Gary said:
I wish to have an open (mdb database without macros and modules)
referencing
a mde database (with only modules or macros). The macros is option.

I have people who want the ability to do minor changes to reports (because
my turn-around time is 24 hrs or less). I was thinking of having an mdb
database that they can do changes and its reference all my modules (VBA
Code)
in another mde database. I don't want people to see my VBA Code. I
believe
with special tools, one can still see the code.

Someone indicated that my mde modules may need changes like Set db =
CurrentDB(), etc.

I would appreciate any suggestions on this.

Thanks,

Gary
Click to expand...

Yes you can do this. Compile your library code into an mde and then, in
your mdb file, set a reference to the mde from Tools, References in a module
window. Use UNC paths rather than drive letters to avoid mapping conflicts.

You can still see your code in the mdb file that you created your mde from.

Keith.
www.keithwilby.com
 
Do I need to change any of my VBA code for referencing?? For example, I
declare Global Arrays and I also reference reports and forms in my VBA code
(i.e. Reports![xxxx]!Text1). I also do the following:

Set db = DBEngine.Workspaces(0).Databases(0)

Sometime I use

Set db = CurrentDb()

Could I just break my database into two parts without any code changes other
than using UNC paths??? What is UNC path???

Make the mde from the part with just Modules and Macros????

Thank You,

Gary
 
Gary said:
I wish to have an open (mdb database without macros and modules) referencing
a mde database (with only modules or macros). The macros is option.

I have people who want the ability to do minor changes to reports (because
my turn-around time is 24 hrs or less). I was thinking of having an mdb
database that they can do changes and its reference all my modules (VBA Code)
in another mde database. I don't want people to see my VBA Code. I believe
with special tools, one can still see the code.
Click to expand...

If the main app is an MDB Access will attempt to resolve the
reference by looking in some directories. Whereas it will do next to
nothing to resolve references for MDEs.

You may need to set the RefLibPaths registry key so Access knows where
to go looking for it. See my Add-in Tips, Hints and Gotchas page at
http://www.granite.ab.ca/access/addins.htm

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
I am dead set against allowing users to modify production databases. If
your database has been split into a FE and BE, you can distribute individual
copies of the FE to each user. Technically, they can modify the FE if you
haven't secured it but I don't recommend it because they will forget to tell
you about changes they made and then be mad when they disappeared because
you pushed out a new copy of the FE.

You could, give them an empty database with links to your BE tables but that
doesn't really help them if they want to modify existing objects. They are
unlikely to have the wherewithal to import a report and find any code or
query pieces that are also necessary. This would be a good feature for
Access -"import related also" would save me a lot of trouble. If your
reports use class modules or procedures/functions in standard modules, you
will need to allow them access to the code to make modifications.

IMHO - 24 hours turnaround is superior responsiveness. I have been trying
to get some constraints added to my production database for 4 months!
Apparently our IT group in the UK doesn't have anything approaching a
service level agreement and they don't trust the folks in the US to make
schema changes.
 
Back
Top