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

Usining Replication

P: n/a
I am creating an application that will need to share data, to exist on a
company's intranet, and to be used by 50+ users. The sharing consists of
only added data. Each user will be able to see, but not change, data
entered by one of the other users. The transaction volume is probably 500
added records per month per user. Does this seem like a good situation for
replication? Since I have never used replication before, what should I do
and not do? Thanks in advance.

Mar 5 '06 #1
Share this Question
Share on Google+
6 Replies


P: n/a
On Sun, 5 Mar 2006 08:38:26 -0800, "NoEd" <ba**********@hotmail.com>
wrote:

I don't think so. Use replication sparingly, and only in situations
that is was designed to be used in (occasionally connected users).
Rather, since everyone is on the same LAN, make it a regular LAN-based
application with a back-end on a file server, and a front-end on each
work station. Build a proof-of-concept if you have reasons to believe
this may be too much for your network.

-Tom.

I am creating an application that will need to share data, to exist on a
company's intranet, and to be used by 50+ users. The sharing consists of
only added data. Each user will be able to see, but not change, data
entered by one of the other users. The transaction volume is probably 500
added records per month per user. Does this seem like a good situation for
replication? Since I have never used replication before, what should I do
and not do? Thanks in advance.


Mar 5 '06 #2

P: n/a
"NoEd" <ba**********@hotmail.com> wrote in
news:12*************@corp.supernews.com:
I am creating an application that will need to share data, to
exist on a company's intranet, and to be used by 50+ users. The
sharing consists of only added data. Each user will be able to
see, but not change, data entered by one of the other users. The
transaction volume is probably 500 added records per month per
user. Does this seem like a good situation for replication?
Since I have never used replication before, what should I do and
not do? Thanks in advance.


Is this question different than it was when you posted it yesterday?
It's already been answered.

From what you write, it doesn't sound to me like you need
replication, as if your users are all on the same LAN, tney can
simply edit data stored in a shared MDB (all users having their own
copies of the front end, though, rather than sharing that). The Jet
database engine is multi-user capable by default, so there's no
problem here.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Mar 5 '06 #3

P: n/a
It is the same questions, but it didn't show up on my newsreader. The only
other question I would have is updates. How are they distributed assuming
50+ users?
"David W. Fenton" <XX*******@dfenton.com.invalid> wrote in message
news:Xn**********************************@127.0.0. 1...
"NoEd" <ba**********@hotmail.com> wrote in
news:12*************@corp.supernews.com:
I am creating an application that will need to share data, to
exist on a company's intranet, and to be used by 50+ users. The
sharing consists of only added data. Each user will be able to
see, but not change, data entered by one of the other users. The
transaction volume is probably 500 added records per month per
user. Does this seem like a good situation for replication?
Since I have never used replication before, what should I do and
not do? Thanks in advance.


Is this question different than it was when you posted it yesterday?
It's already been answered.

From what you write, it doesn't sound to me like you need
replication, as if your users are all on the same LAN, tney can
simply edit data stored in a shared MDB (all users having their own
copies of the front end, though, rather than sharing that). The Jet
database engine is multi-user capable by default, so there's no
problem here.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Mar 5 '06 #4

P: n/a
"NoEd" wrote
It is the same questions, but it didn't show
up on my newsreader. The only other
question I would have is updates. How
are they distributed assuming
50+ users?


If you mean updates to the front end, read the article at
http://accdevel.tripod.com/versioning.htm. At MVP Tony Toews' site,
http://www.granite.ab.ca/accsmstr.htm, you'll find a copy of his Auto FE
Updater, which is used also for distributing updated Front Ends to users.

A key item is: you do not distribute updates, you update the front end and
test it, and distribute the entire updatED front end.

If you are talking about data, all users share the same tables, data, and
relationships, so there is no "distribution".

Larry Linson
Microsoft Access MVP
Mar 5 '06 #5

P: n/a
"NoEd" <ba**********@hotmail.com> wrote in
news:12*************@corp.supernews.com:
It is the same questions, but it didn't show up on my newsreader.
The only other question I would have is updates. How are they
distributed assuming 50+ users?


Well, if you consider that replicating a front end DOES NOT WORK,
that takes replication out of the equation for this task.

The reason you can't reliably replicate a front end is conceptually
IT SHOULDN'T BE REPLICATED AT ALL.

Replication was designed for Jet data, and while forms and reports
and so forth are stored in Jet tables, they are much more
complicated kinds of data than plain old Jet data tables. This
results, over time, in recurrent corruption and eventual loss of the
entire replicated project.

Yes, Microsoft says you can use replication to push out changes, but
Microsoft is wrong -- it doesn't work on a practical basis.

A front end is not data -- it is a program, and it should just be
replaced with a new version. There are a number of ways to
accomplish this, but replication is not one of them.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Mar 6 '06 #6

P: n/a
Larry and David,

Thank you very, very much for your comments and links. They are exactly
what I was looking for.
"David W. Fenton" <XX*******@dfenton.com.invalid> wrote in message
news:Xn**********************************@127.0.0. 1...
"NoEd" <ba**********@hotmail.com> wrote in
news:12*************@corp.supernews.com:
It is the same questions, but it didn't show up on my newsreader.
The only other question I would have is updates. How are they
distributed assuming 50+ users?


Well, if you consider that replicating a front end DOES NOT WORK,
that takes replication out of the equation for this task.

The reason you can't reliably replicate a front end is conceptually
IT SHOULDN'T BE REPLICATED AT ALL.

Replication was designed for Jet data, and while forms and reports
and so forth are stored in Jet tables, they are much more
complicated kinds of data than plain old Jet data tables. This
results, over time, in recurrent corruption and eventual loss of the
entire replicated project.

Yes, Microsoft says you can use replication to push out changes, but
Microsoft is wrong -- it doesn't work on a practical basis.

A front end is not data -- it is a program, and it should just be
replaced with a new version. There are a number of ways to
accomplish this, but replication is not one of them.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Mar 6 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.