I'm just about to put my first runtime project out there in front of some
new users. While the App runs well for those who are running it under a
"real" version of access, I'm curious how to handle updates/bug fixes
when the DB is a runtime version.
Can you still import new/fixed forms/reports/queries into a runtime??
The process for the full version, or runtime version is the same for me.
Regardless if you are using a runtime, or not, you should as a good practice
distribute a mde to your users.
It is not clear if by the above you actually have your users open up your
application in design mode and start importing forms and reports. In
general, those users should not see any of the ms-access interface and stuff
ever. (and, how much training and procedures do you want your clients to
learn?).
The usual approach to update users is to have a spit database. The front end
has no data..and thus you can email, or send updates at a will. This means
you send a whole new mde front end for a single bug fix, or change. If the
back end tables need changes, then either you have to include code that
modifies the tables for you, or have your users send the file back to you
(or, perhaps talk them through this on the phone!). Thus, I usually have a
small table in the back end, and front end that has some "version number"
that checked.
E-mailing a small database with updates/fixes/custom reports has been fine
for the users who have the full version of access.
It is not clear how these updates get into the clients version? As
mentioned, your users should get a mde, and this is regardless of the
runtime or not.
You can certainly send your clients a new mde. As for a mdb, hum? I don't
think you can run code to import forms in the runtime. However, even if I
could import forms etc, I would not count on this (too many things can go
wrong, and stuff like ensuring the code remains in a compiled state etc. is
problematic when you use a mdb). And, another nice feature of mde's is that
un-handled errors don't re-set all global vars like they do with a mdb.
So, best approach here is to "learn" to work with a mde regardless if the
runtime is being used. A mde is more secure, more reliable, and your users
can't mess with them cause you to waste support efforts.
Of course, if you use a split database, then you will need to incorporate
some code to allow re-linking of the tables on startup in case the path name
on the clients computer is different then your development computer.
The above seems to work about the best for me..but some "learning" does have
to take place.
