FE & BE Version Control Tips?

[Tim Marshall]

I usually develop major FE apps in my organization against a single
Oracle back end database. I'm now working on something different that
has a Jet BE and will have back ends all over the place. In fact, the
app is meant to be run on a single stand alone computer, ie, one FE only
against one BE (called a "data file" in my FE app), though there could
be many different BE ("data files") on a single PC. A user may switch
between BEs - I have this functionality working fine. The question mark
comes up when updates affect the structure of the BE.

I wondering what some folks do to "synch" their different versions. For
instance, we all know that requests for enhancements will be made, and
some of these may result in requiring table structural changes and even
additional tables on the BE. What I'm concerned about are people having
a later version of the FE with an earlier version of the BE and that
particular older BE might be lacking some fields/tables the newer FE
might be looking for.

Thanks very much in advance for any suggestions and/or advice in this area.
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "What's UP, Dittoooooo?" - Ditto

[Steve Jorgensen]

On Tue, 06 Sep 2005 00:38:57 -0230, Tim Marshall
<TI****@PurplePandaChasers.Moertherium> wrote:

I usually develop major FE apps in my organization against a single
Oracle back end database. I'm now working on something different that
has a Jet BE and will have back ends all over the place. In fact, the
app is meant to be run on a single stand alone computer, ie, one FE only
against one BE (called a "data file" in my FE app), though there could
be many different BE ("data files") on a single PC. A user may switch
between BEs - I have this functionality working fine. The question mark
comes up when updates affect the structure of the BE.

I wondering what some folks do to "synch" their different versions. For
instance, we all know that requests for enhancements will be made, and
some of these may result in requiring table structural changes and even
additional tables on the BE. What I'm concerned about are people having
a later version of the FE with an earlier version of the BE and that
particular older BE might be lacking some fields/tables the newer FE
might be looking for.

Thanks very much in advance for any suggestions and/or advice in this area.

The company I'm now working for uses the following approach.

- The back-end file includes a database version stored in a field in a table.
- When the front-end is about to link to the back-end, it first runs a series
of procedures, each of which is designed to upgrade a back-end structure from
one version to the next version.
- Each back-end update procedure performs its updates if the back-end version
is the same version it updates from, or does nothing if it is not.

So, a typical case might be a front-end that expects back-end version 4
opening a back-end at version 2. First, the 1-to-2 procedure sees that the
version is not currently "1" and does nothing. Next, the 2-to-3 procedure
sees that the version is "2", and upgrades it to "3". Next, the 3-to-4
upgrade procedure sees that the version is "3" (because it was just upgraded
to 3) and upgrades it to "4".

A possible problem is that you can't open a newer back-end with an older
front-end, so make sure all possible users upgrade their front-ends at the
same time.

[Larry Linson]

"Tim Marshall" wrote

. . . What I'm concerned about are
people having a later version of the
FE with an earlier version of the BE
and that particular older BE might be
lacking some fields/tables the newer FE
might be looking for.

There's an overview of "versioning" in the article at
http://accdevel.tripod.com/versioning.htm. Tony Toews' site,
http://www.granite.ab.ca/accsmstr.htm has a downloadable Front End Updater
that may be useful to you in distributing updates. I suspect the combination
is, at least, a start toward what you are doing.

Larry Linson
Microsoft Access MVP

[Tim Marshall]

Tim Marshall wrote:

Thanks very much in advance for any suggestions and/or advice in this area.

Thanks Steve & Larry. I'll have to delve into the links Larry provided
and I've seen methods similar to what Steve has described in some of the
Oracle apps I manage.
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me