"John Barr" <JohnBarr@discussions.microsoft.com> wrote in message
news:FC8F8655-35A1-491D-86A2-49E09279E295@microsoft.com...
> I am new to replication in SQL Server, and am investigating which option
> would be best for my solution. I have a SQL Server (Server) on our
network,
> and another on in our DMZ. They have access to each other, and I need to
> replicate a database from the SQL Server (Server) on my network to the box
in
> the DMZ. The database is updated frequently on the network and would need
to
> keep the DB copy in the DMZ up to date. Also, changes will need to be
> replicated back from the DB in the DMZ to the DB on the network. Since the
> updates would need to be readily available to either DB once made, I
thoght
> my best solution would be transactional replication. However, after
reading
> the BOL, I am thinking Merge replication would be better since the changes
> can be updated continuously. Can anyone provide me some other insight into
> how to determine the best solution?

"John Barr" <JohnBarr@discussions.microsoft.com> wrote in message
news:3B4891AA-21BB-45E3-AACB-0BC4303AFE04@microsoft.com...
> So, since both the publisher and subscriber will updated via users, use
> Transactional Replication with immediate updating? Basically, the
subscriber
> will be updated via web application on a limited basis, meaning once every
> 10-14 days a few records will be updated. The publisher will be updated
> constatly throughout the day via client application, meaning 1000's of
> transactions daily from 100+ users.
>
> "Hilary Cotter" wrote:
>
> > For bi-directional replication between two sources where only one side
gets
> > updated at any one time, or when you have perfect partitioning use
> > bi-directional transactional replication.
> >
> > For bi-directional replication between two sources or more (but less
than
> > 10) where the majority of the updates originate on the publisher use
> > Transactional replication with queued updating subscribers.
> >
> > For bi-directional replication between two or more sources where the
> > majority of the updates originate on the publisher and you have very
well
> > connected always up links between the publisher and subscribers use
> > transactional replication with immediate updating. Keep in mind there
will
> > be added latency to every subscriber originating transaction as it is
> > committed to the subscriber database.
> >
> > For every other case use merge.
> >
> > At this time, I would look at bi-directional replication and partition
both
> > sides to reduce the possibility of conflicts. If you cannot guarantee
that
> > you will ever have more than 2 servers, I would use merge.
> >
> >
> > --
> > Hilary Cotter
> > Looking for a SQL Server replication book?
> > http://www.nwsu.com/0974973602.html
> >
> > Looking for a FAQ on Indexing Services/SQL FTS
> > http://www.indexserverfaq.com
> > "John Barr" <JohnBarr@discussions.microsoft.com> wrote in message
> > news:FC8F8655-35A1-491D-86A2-49E09279E295@microsoft.com...
> > > I am new to replication in SQL Server, and am investigating which
option
> > > would be best for my solution. I have a SQL Server (Server) on our
> > network,
> > > and another on in our DMZ. They have access to each other, and I need
to
> > > replicate a database from the SQL Server (Server) on my network to the
box
> > in
> > > the DMZ. The database is updated frequently on the network and would
need
> > to
> > > keep the DB copy in the DMZ up to date. Also, changes will need to be
> > > replicated back from the DB in the DMZ to the DB on the network. Since
the
> > > updates would need to be readily available to either DB once made, I
> > thoght
> > > my best solution would be transactional replication. However, after
> > reading
> > > the BOL, I am thinking Merge replication would be better since the
changes
> > > can be updated continuously. Can anyone provide me some other insight
into
> > > how to determine the best solution?
> >
> >
> >