Prev: DateAdd - passing interval fom another field
Next: Energy Saving Tips
From: ThomasH on 1 Jul 2010 07:51
Hi NG!

Three physical locations (A, B and C) share the same database. When a
person at location A puts something in the database, it should be
updated for B and C.

My best solution is 1 database at location A, which also has a terminal
server that users from B and C log on to. Voila, the see the same data.

If that's not an option, what's the best solution?

We've got lots of small alterations to the data in the course of the
day, so I'm thinking Merge Replication. But we need something like
instant replication... is that feasible?

Hope you can pitch in :)
Thomas
From: Erland Sommarskog on 1 Jul 2010 17:15
ThomasH (thomasherskind(a)gmail.com) writes:
> Three physical locations (A, B and C) share the same database. When a
> person at location A puts something in the database, it should be
> updated for B and C.
>
> My best solution is 1 database at location A, which also has a terminal
> server that users from B and C log on to. Voila, the see the same data.
>
> If that's not an option, what's the best solution?

Certainly solutions where the database is not only logically the same,
but also the physically are very palatable, since introducing replication
raises the level of complexity considerably.

> We've got lots of small alterations to the data in the course of the
> day, so I'm thinking Merge Replication. But we need something like
> instant replication... is that feasible?

Replication is not my game, so I don't know how fast merge replication is.
The alternative would be some custom-built, which may be feasible if only
a small amount of tables are involved. This could with Service Broker.
But it's a not path I would take easily.


--
Erland Sommarskog, SQL Server MVP, esquel(a)sommarskog.se

Links for SQL Server Books Online:
SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx
SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx
SQL 2000: http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx

From: ThomasH on 2 Jul 2010 02:47
> The alternative would be some custom-built, which may be feasible if only
> a small amount of tables are involved. This could with Service Broker.

Thanks for the input. We're dealing with something like 40 tables, and
something in the neigbourhood of 500 - 2000 MB. Nothing crazy :) mind
you, but we do need something like real time access from several
different locations.

We tried accessing a single database over a vpn 100 mbit line, but it
got bogged down pretty quickly. Seems a lot of superflous data was sent
back and forth.

So we're back at replicating the database...
From: Erland Sommarskog on 2 Jul 2010 02:57
ThomasH (thomasherskind(a)gmail.com) writes:
> We tried accessing a single database over a vpn 100 mbit line, but it
> got bogged down pretty quickly. Seems a lot of superflous data was sent
> back and forth.

Obvoiusly, with a slow connection, you need to make sure that the clients
are lean in their data access. Which may or may not be within your control.


--
Erland Sommarskog, SQL Server MVP, esquel(a)sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
 | 
Pages: 1
Prev: DateAdd - passing interval fom another field
Next: Energy Saving Tips