Working on a production database

D

dhstein

I will soon be at the point where I will allow the users to actually use this
database I've developed. That's the good news. The bad news is I can no
longer make any changes as easily as I have been doing. So I'll split the
database and distribute the runtime to the users - this has already been
demonstrated - it works - no problem. But from this point forward, if I make
changes, I think this is what I need to do - so tell me if I'm on the right
track:

Case 1 - No modifications to the table structures:

In this case I can work on the forms and write VBA code and keep a copy of
the tables on a "SUBST" drive that uses the same drive letter and path as the
real tables. When I'm ready to release the code, package the application and
reinstall for the users. This should update their .accdr file and leave the
tables on the network alone.

Case 2 - Changes to the table structures

I'm guessing I want to avoid this as much as possible, but the only way I
see how to do this is to make the changes during non-production hours.

I guess I'm just looking for some confirmation and advice from people who
have done this and perhaps can point out some pitfalls or gotchas that I may
not be aware of. Thanks for any help on this.
 
G

Gina Whipp

DHStein,

Case 1 & 2 - To make changes to tables you will have to do so when 'no one
is looking'. OR if you THINK you might want to add fields put in 'Extra'
Fields name them whatever you like. So let's say you have Extra1, Extra2,
Extra3, now you have three extra fields to 'add' to the front end should you
need to without ever 'touching' the back tables.

To make updates to the front end, take a look at
http://www.granite.ab.ca/access/autofe.htm BIG THANK YOU to Tony Toews!
This little gem makes updating front ends a breeze!

--
Gina Whipp

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

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

Peter Hibbs

It is inevitable that at some time you will want to add a new field or
table to the back-end file. The easiest method to do this is to add
some code to your front-end file which can make the changes to the
back-end file automatically, have a look at the Back End Update
Utility at :-

http://www.rogersaccesslibrary.com/...p?FID=21&SID=5debzz2c87c6957859f13b1d2zcccfb4

You could, as you say, try and keep the pathname of the back-end file
on your development system the same as the user's system but that is
fraught with danger. A much better way is to just re-link the tables
each time you update their front-end file with a new version. You can
find code to do this in the BE_Relink.mdb example at the above Web
site.

If the user has a Network system, you will need to update the
front-end file on each PC whenever you give them a new version, the
Front End Updater Utility at the same site can do that.

HTH

Peter Hibbs.
 
M

Mark Andrews

On Case 1 if your users are savy enough that they don't mind locating the
back-end database you can skip the SUBST drive and just use code that "when
it can't find the back-end linked tables it prompts for the back-end to use
for relinking". I like the code on allen brownes site.

Just change the front-end and give them a new front-end.

I'm sure there are ways to double check/force everyone to be using the
latest version of the front-end as well. Store version number in front-end
and back end etc....

HTH,
Mark
 
P

Peter Hibbs

Gina,

I have no experience of SQL Server Back Ends so I don't think so.
Perhaps it could be modified to that, I don't know. If anyone wants to
have a go then feel free to use my code.

Peter Hibbs.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top