Modify Forms in Separate MDB

  • Thread starter Thread starter Jason E
  • Start date Start date
J

Jason E

I have a distributed MDB that I would like to modify
programmatically rather than sending out a whole new MDB
to replace it.

What I would like to do have users open a separate MDB
and run code which opens the MDB to be changed and
modifies the layouts of some forms and reports. The
modifications should not impact the compiled state of the
MDB.

It seems that you can modify another MDB's tables and
queries programmatically, but I can't find a way to get
to its Forms or Reports to modify them.

Is there any way to do this?

Thanks

Jason
 
What does this mean: "The modifications should not impact the compiled state
of the MDB."? Also what does it mean to have a distributed MDB?

Your best bet is to separate the database and the application into two
separate MDB files. Compile the application to an MDE and distribute the
MDE. Any new changes would involve distributing the MDE file.

Dan
 
I meant that the changes I want to make (changing the
size and location of controls on a form) I would not
expect to lose the compiled state of the MDB.

By distributed I mean that it is in use in several
hundred locations worldwide. It is also a critical app
for the client. This is why the client would prefer not
to force these hundreds of users to run an "install"
procedure.

We have created new installs in the past, but were hoping
to avoid the more significant development and testing
involved in that and find a way to make some minor mods
to the existing MDB's.

The database and app are separated. We have recommended
using MDE, but so far the client is resisting the change.

Thanks

Jason
 
I do not see your problem, if the database and app are separated what is the
big deal with sending out a compiled MDE file for the application? There is
no install just overwrite the existing copy. BTW and MDB file is not
compiled
 
There are a few issues - most of them related to the
conservative nature of the client - wanting to be very
sure new versions do not interrupt the use of the product.

Reasons the client does not want to send out new versions
very often:
- Hard to communicate/force all site to comply with
implementing new version
- Each implementation has chosen their own installation
location for front and backend MDB's, so some concern
with sites getting the attachment to their backends
correct.
- There is some user/site specific data in the front
end, so need to get that info into the new front end
- Auditors and IT group demand extensive testing of new
releases, so time and money are a factor.

Back to the original question - do you know of any way to
programmatically change forms in one MDB from another MDB?

Thanks
 
Jason,

Now that I understand your reasoning, I would suggest you begin to look for
another solution for your front end application.

I have used the Dot Net no-touch deployment system with great success. If
each of your clients has an IIS Webserver you could distribute the updates
to each of their IT departments. They could test the new version and simply
place it on their web server when they have completed their QA. The cool
thing is that the applcation can be updated any time and the next time the
user starts the application they will automatically get the updates.

The down side is that (a) your application must be created so it can be
distributed via XCOPY and (b) thier web server must always be up.

The other solution is to create a web interface, but you know the ups /
downs with that approach.

Good Luck,
Dan
 
There are some methods to modify the objects in another mdb
file. See Help for the CopyObject method, but I don't think
that's very useful. You could also create a module in your
next deliverable to the end uses that takes care of self
modifying the db's objects based on some meta language you
would have to make up and provide you own interpretor for.

That last idea was said facetiously as I would never go
that route.

But, lets step back and look at your reasons for asking this
question. If you can not get the client sites to do a
simple file copy to update their front end, what makes you
think thay're going to run another mdb that takes the far
riskier approach of fiddling with their current version.
The resting of this modification program would be an order
of magnitude more complex then testing a new version.

Take a look at Tony's FE Updater at
http://www.granite.ab.ca/access/autofe.htm

You are probably experienced enough to modify that to
preserve the client specific data and backend location
fairly easily.
 
Back
Top