Just place a table in the back end.
Put a in a few fields. for example, I have a table called "tblDefaults" in
virtually all of my applications.
In that table is stuff like default city, default area code.
I mean, in virtually every application I written for many years, even NON
ms-access ones, there
always been a form with all kinds of defaults that the user can setup.
(here is a picture of one in ms-access)
http://www.kallal.ca/ridestutorialp/editlists.htm
Note how in the above there are many defaults. I don expose all of these
fields
to the user. in the above "setup" form, but many such as city, area code
etc.
is exposed on that form.
One of the fields in that table (that table has only ONE record by the way).
is the version number of the back end.
So, it is rather common to have a table in the back end that stores all kind
of things.
I mean, were do you now store defaults and other things that you need to
save in your
application?
So, it always a good idea to give your users some defaults for things like
city, or phone numbers. And, I tend to make this is user screen, so you
don't have to change the actual VBA code in the system because someone wants
a different city default.
And, I also tend to have a few tables in the front end that stores
preferences for a user that are NOT for all other users.
So, you could have a table in the front end also that can store things (such
as uses default printer, or whatever).
You would develop the new front end...test it. When you happy, you place the
new version on the server, and then go and edit the back end table with your
version number.
When you run the new front end, it simply opens the table in the backend,
and opens the table in the front end..and compares the two version numbers.
At that point you can run some code to update, or tell the user a new
version need be installed.
If you don't have actual physical access to opening and using the back end,
then you use code, and the following would make sense:
If the FE current version number is LESS THEN back end, then you tell the
user they have to upgrade (or, perhaps you have to code that downloads a new
version from the web or the server). IF the FE version is GREATER then the
back end version, then your code is a NEW version. You new FE will then
simply update that table in the back end to the SAME new version number.
Thus, we now know that a newer version has WORKED WITH and TOUCHED the back
end. From that point own, all other users will be forced to upgrade to this
newer version.
The code is rather easy.
The code will look like:
Set gblrecRides = CurrentDb.OpenRecordset("tblDefaults", dbOpenSnapshot)
' check version stuff
If gblrecRides!RidesVersion > gblRidesVersion Then
If MsgBox("A new and improved version of rides is available" & vbCrLf
_
& "Please click on Ok to perform the upgrade", vbInformation +
vbOKCancel, AppName) = vbOK Then
Call JumpToUpGrade
and, the FE version was earlier set in code via:
Set rstLinkrec = CurrentDB.OpenRecordset("tblLinkCheck")
rstLinkrec.MoveFirst
gblRidesVersion = rstLinkrec!RidesVersion
I would think that if you reach the point of developing a good working
application like you have, then comparing a simple field value in two tables
is not going to be much of a challenge for you.
So, the actual code here is not hard, however, sitting down and coming up
with something that works best for you does take some consideration on your
part (hence, that why your asking questions!!).
I think in most cases, you certainly do need some custom-re-link code at
startup. The re-link code will not run each time, but you should have
something in the code that tries to open a back end table, and if that fails
(on error goto), then you know the back end is not available. At that point,
you can run your re-link code (it can either prompt the user to browse to a
back end, or simply read a file with the last known back end path).
There is an example of re-link code here:
http://www.mvps.org/access/tables/tbl0009.htm
And, the pop open the file browse dialog code is here:
http://www.mvps.org/access/api/api0001.htm
I think just about all of us have used the above two bits of code to roll
some re-link system. In all my applications, I now write out the back end
path name to a text file called path.ini in the SAME directory as my FE
application. My startup code then opens up this .ini file, and if the path
name in that lini file DOES NOT match the current linked path name...then I
re-link. This allows me to update my clients applications, but THEY
determine the location of the back end.And, they only have to set this
location once...and any new updates will then re-link automatic based on
this last known path name. You could even use the windows registry if you
wanted.
As mentioned, Tony has a automatic updater for you, and you can well not
worry about updating when a new version if if you use his system. (but, his
system does much assume you can be "on-site" and install the new version.
However, you can well tell a client to place the new updated version on the
server..and still use Tony's FE updater. His solution is simply amazing. It
really a commeral product for free.
I rolled my own update system, and MANY of us will do this (in fact, most of
us will have come up with something along the way). I rolled my own because
I wanted a system that updates from the web. So, I even used a FTP library,
and can now download new updates from the web.
The FTP code examples can also be found at the above
www.mvps.org/access
web. There is all kinds of useful code examples at that site...so, bookmark
it...
I also wanted code that will FORCE the user to upgrade their FE if they
attempt to use a OLDER version of the FE that I might not want to work on
the data anymore.
Really, your are only much limited by your imagination here as to how this
will work.
It really up to you to pick something that works best for your given
situation. For example, do you always have physical access to the network,
or is it 100% remote and you never meet the client face to face (I have many
of those types of customers also).
here is what my ms-access web update process looks like:
http://www.kallal.ca/ridestutorialp/upgrade.html
So, it is different horses for diffent courses. You have TONS of choices,
and lots of example code etc. to build something that can manage your update
issues for you....
