By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,928 Members | 1,210 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,928 IT Pros & Developers. It's quick & easy.

Design changes to a replicated database

P: n/a
Hi,

My company has an old access database which has been in use for many
years now by a few employees. I need to make some design changes to
one of the forms, but I'm not sure how I should go about doing this. I
have designed databases with access before, but not when replication
was used.

So, should I first get everyone out of the database, then make a copy
of the database to which I will add my changes to. Then finally,
delete the old database (after backing up), and rename the copy to
that of the old database.

Of course, everyone will then have to open the new version before
chosing Click Tools -Replication -Create Replica...

Any other tips?

Thanks,

Aine.

Aug 6 '07 #1
Share this Question
Share on Google+
1 Reply


P: n/a
ai********@yahoo.com wrote in
news:11**********************@r34g2000hsd.googlegr oups.com:
My company has an old access database which has been in use for
many years now by a few employees. I need to make some design
changes to one of the forms, but I'm not sure how I should go
about doing this. I have designed databases with access before,
but not when replication was used.

So, should I first get everyone out of the database, then make a
copy of the database to which I will add my changes to. Then
finally, delete the old database (after backing up), and rename
the copy to that of the old database.

Of course, everyone will then have to open the new version before
chosing Click Tools -Replication -Create Replica...
There are a number of bad problems lurking in the situation you
describe:

1. there is no Access application that should not be split into
front end and back end.

2. replication works repliably only for back end data tables, so
your front end should not be replicated, only the back end.

3. when you make a change to the front end, you just give your users
a new copy of it, leaving the replicated data tables alone.

To split your current application, the easiest thing to do is create
a new MDB and import everything into it except the tables. Then in
the new MDB, create links to the back end replica.

In the DESIGN MASTER, delete everything but the tables. To convert
over to the new version, send everyone the new front end, and tell
them to synch with the updated repica you use as a hub for synching.

If everyone has the same location for their app, there should be no
need to relink tables. But if they store the app in different
locations on their PCs, then they will either have to use the Linked
Table Manager each time you send out a new front end, or you will
have to provide code that does the relinking for them. There's
plenty of code around that will relink to a back end in the same
folder as the front end.

Last of all, you should consider why the app is replicated. If the
users are all connected to the same LAN at all times, there is no
role for replication at all.

If, on the other hand, they are using laptops and need to edit data
in the field, that's a perfectly good justification for replication.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Aug 6 '07 #2

This discussion thread is closed

Replies have been disabled for this discussion.