Multi User Replication...

  • Thread starter Thread starter Goobz
  • Start date Start date
G

Goobz

Would like some advice from people...

I have a database here on the network server that is the Replication
Master.

I have 3 or 4 users that are using "Replicated" versions of the
database. What happens if I get more than one user updating the same
record. Who wins the replication!?

Anyone have any other suggestions!? Right now, it is basically one
database being updated locally, then once a week or so, copying the
whole 136MB database via VPN to the server to update the old one.

Thanx!
 
I seriously hope that this is a split database (frontend/backend) with the
backend being the replicated part. You should NOT use replication with an
mdb file with forms, reports, etc. in it.

See here for some real good info on Replication:

http://www.dfenton.com/DFA/Replication/index.php?title=Main_Page
--
Bob Larson
Access World Forums Super Moderator
Utter Access VIP
Tutorials at http://www.btabdevelopment.com
If my post was helpful to you, please rate the post.
__________________________________
 
There is a conflict which must be resolved by a designated user, or by a
rule (Like last one wins)

Has the database been split so the tables are the only thing which is
replicated? Are you compacting the database before sending to the server? Do
both.
 
I seriously hope that this is a split database (frontend/backend) with the
backend being the replicated part. You should NOT use replication with an
mdb file with forms, reports, etc. in it.

See here for some real good info on Replication:

http://www.dfenton.com/DFA/Replication/index.php?title=Main_Page
--
Bob Larson
Access World Forums Super Moderator
Utter Access VIP
Tutorials athttp://www.btabdevelopment.com
If my post was helpful to you, please rate the post.
__________________________________









- Show quoted text -
Click to expand...

That brings up a valid question... The database I am working on right
now, the whole thing is set to replicate. The form, queries, tables,
etc... The person that originated this database set it up that way...
If I split the database, what advantage/disadvantage does that give
me!?
 
Goobz said:
No. It it a complete database.
Click to expand...

Then you should not be using replication for it. You run a MAJOR risk of
corruption besides your current problem. Replication is NOT intended to be
able to distribute design changes for forms, reports, code, etc. It is ONLY
intended for maintaining data within TABLES.

--
Bob Larson
Access World Forums Super Moderator
Utter Access VIP
Tutorials at http://www.btabdevelopment.com
If my post was helpful to you, please rate the post.
__________________________________
 
Then you should not be using replication for it. You run a MAJOR risk of
corruption besides your current problem. Replication is NOT intended to be
able to distribute design changes for forms, reports, code, etc. It is ONLY
intended for maintaining data within TABLES.

--
Bob Larson
Access World Forums Super Moderator
Utter Access VIP
Tutorials athttp://www.btabdevelopment.com
If my post was helpful to you, please rate the post.
__________________________________
Click to expand...

Then how would you recommend I setup the database!? Stop the
replicating, and split the database!? If I do that, will I be able to
have multiple people in the database at one time!?
 
Goobz said:
Then how would you recommend I setup the database!? Stop the
replicating, and split the database!? If I do that, will I be able to
have multiple people in the database at one time!?
Click to expand...

First split the database. The Master is only used to make replicas, never
for data. Take a replica and use it to create a server copy. A copy of the
front-end should be on each user's machine linked to a replica also on their
machine. Only sync the replicas, never the front-ends.

Read the Replication FAQ:

http://support.microsoft.com/kb/282977/en-us

and David Fenton's articles:

http://www.dfenton.com/DFA/Replication/index.php?title=Main_Page
 
First split the database. The Master is only used to make replicas, never
for data. Take a replica and use it to create a server copy. A copy of the
front-end should be on each user's machine linked to a replica also on their
machine. Only sync the replicas, never the front-ends.

Read the Replication FAQ:

http://support.microsoft.com/kb/282977/en-us

and David Fenton's articles:

http://www.dfenton.com/DFA/Replication/index.php?title=Main_Page
Click to expand...

I will have to follow the steps in setting this all up over the
holiday week.

The other question, is if I have 1 master database, and I create a
users database where they have to login, does that make the database
where it is multi-user capable, and I don't get the someone else has
access message!?
 
:
The database I am working on right
now, the whole thing is set to replicate. The form, queries,
tables, etc... The person that originated this database set it up
that way... If I split the database, what advantage/disadvantage
does that give me!?
Click to expand...

1. avoidance of the huge risk of losing the whole VBA project to
corruption because of replicating forms/reports/etc.

2. better performance on synchs since less has to be synched.

3. all the advantages that come from splitting any Access app,
replicated or not -- split should be the norm, unsplit the rare
exception.
 
m:
What happens if I get more than one user updating the same
record. Who wins the replication!?
Click to expand...

I didn't finish my original answer (I wrote only about column-level
conflict resolution).

In cases where two users update data in the same column, the edit in
the replica with the highest replication priority wins. The Design
Masgter starts out with a priority of 100. Any replicas created from
it have 90% of the replica priority, so they would have 90. A
replica created from a 90 priority replica would have a priority of
81 (i.e., 90% of 90), and so on. When two replicas synchronize edits
to the same field in a replica win for the replica with the higher
priority.

When the replicas have the same priority, it's not really
predictable which edit wins. In Jet 3.5, replica priorities didn't
exist (nor did column-level conflict resolution), and the record
with the most edits would win. I don't know the exact mechanism for
Jet 4 when the replica priorities are the same.

In my replication topologies, the DM is 100, the editing replicas 90
and any synchronization hubs (which never have any edits and server
only as conduits for synchronization operations) are 81. The DM is
never edited, and never really matters in regard to edits.

Another thing to keep in mind:

The "conflict resolver" is actually somewhat misnamed, as it's not
really resolving the conflict so much as *confirming* it. When you
see conflicts, they've already been resolved, in favor of the data
in what is presented as the WINNING RECORD. If you do nothing, the
conflict has already been resolved. The conflict resolver only gives
you the opportunity to confirm that Jet resolved it correctly, or to
override Jet's resolution, or to mix up data from both records into
the winning record (by copying and pasting data from the two
versions of the record).

If you deleted the conflict tables before resolving conflicts,
nothing bad would happen in terms of synchronization. The only thing
you would lose is the opportunity to confirm that the conflicts were
resolved the way you want them resolved.
 
There is a conflict which must be resolved by a designated user,
or by a rule (Like last one wins)
Click to expand...

Not true. Jet automatically resolves the conflict. The records in
the conflict tables (i.e., the data that pops up as the losing
record in the conflict resolver) are really there just to allow you
to confirm that Jet made the right decision in the way that it
resolved the conflict. You could delete the conflict tables without
running the conflict resolver and all conflicts would have been
resolved. You'd just not know *how* they were resolved.

Applications that are most appropriate for replication are ones
where there is little overlap between replicas in terms of the
records that are edited. That is, apps where the same records are
going to be edited in multiple locations are not really appropriate
for replication. However, those kinds of schemas could be converted
to a transaction logging format, where instead of editing a base
record, you replace the old record with a new one (and log the old
one). This would prevent conflicts.

On the other hand, you may *want* to know about conflicts in that
situation, in which case you'd probably want to build a custom
interface to present the new and old versions of the records for
someone to confirm.

But any app in which there are hundreds or thousands of conflicts on
a regular basis is one that is probably ill-suited in its current
design for Jet replication.
 
m:
Would like some advice from people...

I have a database here on the network server that is the
Replication Master.

I have 3 or 4 users that are using "Replicated" versions of the
database. What happens if I get more than one user updating the
same record. Who wins the replication!?
Click to expand...

Depends on a number of factors.

If the users update different fields, then both edits propagate,
since Jet 4 replication is field-based (unless it was converted from
Jet 3.5x -- instructions for getting column-level conflict
resolution, see Question 7 of
http://www.dfenton.com/DFA/Replication/index.php?title=FAQ).
Anyone have any other suggestions!? Right now, it is basically one
database being updated locally, then once a week or so, copying
the whole 136MB database via VPN to the server to update the old
one.
Click to expand...

Well, that's a really bad thing. You can't willy-nilly copy replicas
around and not eventually run into problems. The reason is that this
causes "dead replicas," which are explained in Question 5 of
http://www.dfenton.com/DFA/Replication/index.php?title=FAQ .
Replicas have to be edited and synchronized in place. The only
situation in which you can safely copy a replica is when you're
initializing a new replica location. Once someone opens it (whether
they edit it or not), it can't be moved, except with the Jet
MoveReplica command (available only in Replication Manager and the
TSI Synchronizer).

I can't tell from your explanation why replication is in use at all.
 
David W. Fenton said:
I can't tell from your explanation why replication is in use at all.
Click to expand...

I was just going to post the same comment myself. Actually I still
will.

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
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
Goobz said:
I have 3 or 4 users that are using "Replicated" versions of the
database. What happens if I get more than one user updating the same
record. Who wins the replication!?

Anyone have any other suggestions!? Right now, it is basically one
database being updated locally, then once a week or so, copying the
whole 136MB database via VPN to the server to update the old one.
Click to expand...

Where are these users? Are they on the local LAN or remote? What's
the VPN for?

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
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
Where are these users? Are they on the local LAN or remote? What's
the VPN for?

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 athttp://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog -http://msmvps.com/blogs/access/
Click to expand...

All the users are local... There are 3 users that are working here on
my current database, besides myself. We have a 4th person who has a
local copy of a specific table inside the database, and he just
basically uploads/cuts&pastes the changed information into his table,
which has no relationships anywhere else on the table, at this
point...

Let me ask everyone this...

Over the course of the holiday season, If *you* were to start a new
database from scratch as far as *not* being replicated, but you *must*
keep the information that has been input into the tables, the queries
can be redone, and the forms can be redone. How would you do it? Would
you split the database and give everyone their own copy!? Would you
leave one copy on the LAN and then let everyone just update that one
main copy under a workgroup in a multi-user environment, or what!?

I plan on following the instructions I found on Microsofts website to
remove a replica, and I'm going to start from scratch, somewhat, with
the structure of this database.
 
Goobz said:
All the users are local...
Click to expand...
Let me ask everyone this...

Over the course of the holiday season, If *you* were to start a new
database from scratch as far as *not* being replicated, but you *must*
keep the information that has been input into the tables, the queries
can be redone, and the forms can be redone. How would you do it? Would
you split the database and give everyone their own copy!? Would you
leave one copy on the LAN and then let everyone just update that one
main copy under a workgroup in a multi-user environment, or what!?

I plan on following the instructions I found on Microsofts website to
remove a replica, and I'm going to start from scratch, somewhat, with
the structure of this database.
Click to expand...

Definitely split the MDB into an FE of which each user has their own
copy and a BE which resides on the server. See below for more
details.

There is no need to start over again unless you really, really want
to.

0) MAKE A BACKUP!

1) Remove the replication.

2) Import queries, forms, reports, macros and modules into a new FE
MDB.

3) Link from the FE MDB to the tables in the BE MDB.

4) Have a double of your favourite beverage. (I'm sure I've missed
something but nothing too serious.)

You want to split the MDB into a Front End MDB containing the queries,
forms, reports, macros and modules with just the tables and
relationships in the Back End MDB. 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
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
I will have to follow the steps in setting this all up over the
holiday week.

The other question, is if I have 1 master database, and I create a
users database where they have to login, does that make the database
where it is multi-user capable, and I don't get the someone else has
access message!?
Click to expand...

In order to make a database multi-user capable over a network, the back-end
must be on a server and everyone must have all permissions on the folder
except Full Control. Logging in has no effect on data, just on database
permissions.
 
Definitely split the MDB into an FE of which each user has their own
copy and a BE which resides on the server.   See below for more
details.

There is no need to start over again unless you really, really want
to.  

0) MAKE A BACKUP!

1) Remove the replication.

2) Import queries, forms, reports, macros and modules into a new FE
MDB.

3)  Link from the FE MDB to the tables in the BE MDB.

4) Have a double of your favourite beverage.  (I'm sure I've missed
something but nothing too serious.)

You want to split the MDB into a Front End MDB containing the queries,
forms, reports, macros and modules with just the tables and
relationships in the Back End MDB.  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
athttp://www.granite.ab.ca/access/splitapp/for more info.  See the
Auto FE Updater downloads pagehttp://www.granite.ab.ca/access/autofe.htmtomake 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 athttp://www.granite.ab.ca/accsmstr.htm
   Tony's Microsoft Access Blog -http://msmvps.com/blogs/access/- Hidequoted text -

- Show quoted text -
Click to expand...

So then basically when you are saying "Linked tables to the BE on the
server", basically you are saying link them through the Link Table
Manager!? I currently have one table linked, "Employee Master", which
I am linking from another database currently..
 
In order to make a database multi-user capable over a network, the back-end
must be on a server and everyone must have all permissions on the folder
except Full Control. Logging in has no effect on data, just on database
permissions.
Click to expand...

The backend or the complete database!?
 
Back
Top