Usining Replication

[NoEd]

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.

[Tom van Stiphout]

Re: Usining Replication

On Sun, 5 Mar 2006 08:38:26 -0800, "NoEd" <badbeat_2006@h otmail.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.

[color=blue]
>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.
>
>[/color]

[David W. Fenton]

Re: Usining Replication

"NoEd" <badbeat_2006@h otmail.com> wrote in
news:120m50e6es aubf2@corp.supe rnews.com:
[color=blue]
> 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.[/color]

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/

[NoEd]

Re: Usining Replication

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" <XXXusenet@dfen ton.com.invalid > wrote in message
news:Xns977D944 0E771Cf99a49ed1 d0c49c5bbb2@127 .0.0.1...[color=blue]
> "NoEd" <badbeat_2006@h otmail.com> wrote in
> news:120m50e6es aubf2@corp.supe rnews.com:
>[color=green]
>> 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.[/color]
>
> 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/[/color]

[Larry Linson]

Re: Usining Replication

"NoEd" wrote
[color=blue]
> 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?[/color]

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 "distributi on".

Larry Linson
Microsoft Access MVP

[David W. Fenton]

Re: Usining Replication

"NoEd" <badbeat_2006@h otmail.com> wrote in
news:120mihfiuu 7l243@corp.supe rnews.com:
[color=blue]
> 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?[/color]

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/

[NoEd]

Re: Usining Replication

Larry and David,

Thank you very, very much for your comments and links. They are exactly
what I was looking for.


"David W. Fenton" <XXXusenet@dfen ton.com.invalid > wrote in message
news:Xns977DBFD 447B72f99a49ed1 d0c49c5bbb2@127 .0.0.1...[color=blue]
> "NoEd" <badbeat_2006@h otmail.com> wrote in
> news:120mihfiuu 7l243@corp.supe rnews.com:
>[color=green]
>> 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?[/color]
>
> 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/[/color]