Adding database design changes to a database copy

[Guest]

I have the following database environment. My users enter data into the
database on one computer, and I make design/form/report changes to a copy on
another computer. I want to update the users database design without
changing their data. I thought that I could use the replica database, but I
only want to modify the design and not the data, and the replica synchronizes
both. If I use the import/export functions, I might not remember to get all
the changes. How does industry handle this situation? I figure that it must
be a common problem to have a separate development and production area.

 

[SusanV]

Is the database split? It should be, so that on the (hopefully) rare
occasion that you need to make changes to the table, make changes to the
backend while users are not accessing it (backup first of course). For
changes to forms, reports etc, make changes to the front-end and
redistribute.

 

[SusanV]

BTW, there are far more reasons than this to split the database:
http://www.access.qbuilt.com/html/gem_tips1.html#SplitDB

 

[Tony Toews [MVP]]

I have the following database environment. My users enter data into the
database on one computer, and I make design/form/report changes to a copy on
another computer. I want to update the users database design without
changing their data. I thought that I could use the replica database, but I
only want to modify the design and not the data, and the replica synchronizes
both. If I use the import/export functions, I might not remember to get all
the changes.

To add to Susan's comments.

1) Replication is *not* designed to replicate objects other than
tables.

2) You want to split the MDB into a front end containing the queries,
forms, reports, macros and modules with just the tables and
relationships. The FE is copied to each network users computer. The
FE MDB is linked to the tables in the back end MDB which resides on a
server. You make updates to the FE MDB and distribute them to the
users, likely as an MDE.

See the "Splitting your app into a front end and back end Tips" page
at http://www.granite.ab.ca/access/splitapp/ for more info. See the
Auto FE Updater downloads page
http://www.granite.ab.ca/access/autofe.htm to make this relatively
painless.. The utility also supports Terminal Server/Citrix quite
nicely.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

 

[Guest]

Thank you so very much!

Is the database split? It should be, so that on the (hopefully) rare
occasion that you need to make changes to the table, make changes to the
backend while users are not accessing it (backup first of course). For
changes to forms, reports etc, make changes to the front-end and
redistribute.