db backend upgrades

[swas]

Hello,

I need to explore the best way to manage upgrades on a customer backend db,
of which there will be many over time.

My initial thought is to supply a new empty backend db, and either

a) import all data from the earlier current customer db, or
b) programatically step through the two db's and ensure all customer tables
have the same fields and properties.

Either of the above processes would be controlled by the new frontend code
supplied to the customer.

Being new to this level of coding, I am curious if there is a 'best
practice' approach. Reading / searching for links doesn't reveal much.


Thanks in advance

swas

 

[Tom van Stiphout]

On Sun, 21 Mar 2010 17:56:01 -0700, swas

In a similar situation with a commercial application I did this:
* Maintain a BackendVersionNumber in the back-end.
* Write code in the front-end that can rev the BE from version X to
version Y.
* Check the BE version at startup time, and apply all changes not yet
made.
* Of course we're keeping backups all along.

-Tom.
Microsoft Access MVP

 

[Gina Whipp]

swas,

Your code should be in your front end or are you just adding fields? Here
you go...

http://www.peterssoftware.com/beu.htm

--
Gina Whipp
2010 Microsoft MVP (Access)

"I feel I have been denied critical, need to know, information!" - Tremors
II

http://www.regina-whipp.com/index_files/TipList.htm


Hello,

I need to explore the best way to manage upgrades on a customer backend db,
of which there will be many over time.

My initial thought is to supply a new empty backend db, and either

a) import all data from the earlier current customer db, or
b) programatically step through the two db's and ensure all customer tables
have the same fields and properties.

Either of the above processes would be controlled by the new frontend code
supplied to the customer.

Being new to this level of coding, I am curious if there is a 'best
practice' approach. Reading / searching for links doesn't reveal much.


Thanks in advance

swas

 

[swas]

Gina,

They are great, thanks (The link you suggested had further links also), and
just what I was looking for.

I assume making changes to tables (After backing up) where live data is
stored is the preferred option, rather than importing all data into a new
version back end.

Much appreciated.


swas

 

[Gina Whipp]

swas,

Yes, as you really should never have to worry about the tables once created.
So if you have to make additions then make a back-up, make changes and
hopefully you can delete the back-ups... of course, test your changes and
hold back-up for a few days just in case. Also, if you *think* you're going
to have make more additions then add some extra fields...

UserDefined1
UserDefined2
etc...

I did that once when I had a feeling and they came in handy. Add a few text
and perhaps one numeric!

--
Gina Whipp
2010 Microsoft MVP (Access)

"I feel I have been denied critical, need to know, information!" - Tremors
II

http://www.regina-whipp.com/index_files/TipList.htm

Gina,

They are great, thanks (The link you suggested had further links also), and
just what I was looking for.

I assume making changes to tables (After backing up) where live data is
stored is the preferred option, rather than importing all data into a new
version back end.

Much appreciated.


swas

 

[swas]

Tom,

Thanks for that. It is along these lines I was thinking, though makes me
more confident to be 'ratified' thought...


Regards


swas

 

[swas]

Gina's suggested link also had a further link for another update utility by
Peter Hibbs at

http://www.rogersaccesslibrary.com/forum/forum_posts.asp?TID=410

I tried this and it works great. As simple as importing a few objects into
the front end, using the supplied form to do changes on the developer back
end, and when your front end is distributed it automatically updates the
customers back end.

Great. Easy. Recommended.


Thanks for the input.


swas