LB wrote:
I want to have the upgrade send me an email silently whenever a user
upgrades. I've done this with clients where I support in-house, and my
boss thought it was a great idea since most of our support calls were
the result of not using the right version.
What an interesting topic. I can't add to the voices of those who have
answered, but have you considered a mechanism whereby a front end will
not operate if it is not the correct version? Could something like the
following help?
I'm really not sure how to remotely update a back end with updates, but
in my situation, I run Access FEs on Oracle backends. What I do is have
the version number stored in a table called something like _Version
(with a prefix appropriate to the application. The version table
includes the equivalent of Access memo fields for technotes, general
"layman" notes about why an update was required, etc. There are
separate numeric fields for version, release, maintenance which come
together to create a 2.02.03 sort of structure (I don't know if there is
a standard for this sort of thing, I came up with a general adaptation
of stuff I've seen on other applications). Here are some comments from
a typical app:
'
'Version (TTS_VERSION) - Major data structure change
'
'Release (TTS_RELEASE) - GUI change, minor data structural changes
'
'Maintenance Update (TTS_MAINT) - bug fix only, no changes to
'GUI, ie, appearance of forms.
'Changes to message boxes, prompts permitted.
'
'Minimum Maintenance (TTS_MAINT_MIN) - if Tim's
'TMA Time Sheets© FE maintenance version is different
'from current, what is the minimum maintenance release
'a user can "get away with"? If you want no
'tolerance, here, enter THE SAME NUMBER AS THE
'CURRENT MAINTENANCE VERSION.
The version, release and maintenance update are stored in a standard
module as CONSTANTS.
All my front ends have a routine on the splash and/or "about" form that
checks the version table using Oracle related dmax type functions to get
the highest version.release.maintenance. If those values do not match
what is stored in the FE constants (or are not within the tolerance of
the minimum maintenance release number), the app won't start.
Once you put this together and store it in a module (you can automate
the "new version" process to readily increase a version number component
and make sure what is written as the constants matches), the module,
forms (I use a "release notes" form that shows comments about the
different versions), you can transfer this from app to app with just
renaming of tables/fields necessary.
It works quite well. Essentially, if you have the wrong version, the
app spits a message and tells you to follow your update procedure. I
suppose I could automate the update procedure as well, but I haven't.
--
Tim
http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me
