Replication or bcp or DTS?

[Rohit]

Hi,
I have 2 instances of databases in 2 different cities.Data entry /
updations are going on at both the sides.At any point of time data in
both the databases should be same.Currently every alternate day, i am
performing update / insert / deletes on incremental basis on both the
sides.
Can I implement replcation? What r the requisites I have to follow for
replication?

I do not have permenant connectyvity but I need to connect using ISDN
line to a remote location as and when required for doing
synchrinisation of data.

Thanks in advance.

Regards
Rohit

--
Posted using the http://www.dbforumz.com interface, at author's request
Articles individually checked for conformance to usenet standards
Topic URL: http://www.dbforumz.com/General-Disc...ict236236.html
Visit Topic URL to contact author (reg. req'd). Report abuse: http://www.dbforumz.com/eform.php?p=819975

[Erland Sommarskog]

Rohit (Us************@dbForumz.com) writes:

I have 2 instances of databases in 2 different cities.Data entry /
updations are going on at both the sides.At any point of time data in
both the databases should be same.Currently every alternate day, i am
performing update / insert / deletes on incremental basis on both the
sides.
Can I implement replcation? What r the requisites I have to follow for
replication?

I do not have permenant connectyvity but I need to connect using ISDN
line to a remote location as and when required for doing
synchrinisation of data.

I'm a little confused, since you say that at any point in time, the
contents of the databases should be the same. But then you talk about
not having permanent connectivity. Is that the connectivity between
the databases, or your own connectivity.

The gist of replication is that the I in ACID for transactions is
relaxed. That is, transactions should normally be Atomic, Consistent,
Immediate and D-something. With replication, you say that I does not
matter. A transaction can be replicated later at any time. This is good
if you have disconnected servers. For connected servers, replication
can still be acceptable, since the delay in most cases will not be
noticeable.

Since you need to send data in both directions, it looks as if you are
into merge replication. There are probably a bunch of requirements,
for instance the table must have GUID as keys. And then you need rules
to handle conflicts. (What if the same row is updated at both sites?)

My own knowledge only goes as far about this, so I would recommend you
to ask in microsoft.sqlserver.public.replication.
--
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp

[Rohit]

"" wrote:

Rohit (Us************@dbForumz.com) writes:

I have 2 instances of databases in 2 different

cities.Data entry /

updations are going on at both the sides.At any point of

time data in

both the databases should be same.Currently every alternate

day, i am

performing update / insert / deletes on incremental basis on

both the

sides.
Can I implement replcation? What r the requisites I have to

follow for

replication?

I do not have permenant connectyvity but I need to connect

using ISDN

line to a remote location as and when required for doing
synchrinisation of data.

I'm a little confused, since you say that at any point in
time, the
contents of the databases should be the same. But then you
talk about
not having permanent connectivity. Is that the connectivity
between
the databases, or your own connectivity.

The gist of replication is that the I in ACID for transactions
is
relaxed. That is, transactions should normally be Atomic,
Consistent,
Immediate and D-something. With replication, you say that I
does not
matter. A transaction can be replicated later at any time.
This is good
if you have disconnected servers. For connected servers,
replication
can still be acceptable, since the delay in most cases will
not be
noticeable.

Since you need to send data in both directions, it looks as if
you are
into merge replication. There are probably a bunch of
requirements,
for instance the table must have GUID as keys. And then you
need rules
to handle conflicts. (What if the same row is updated at both
sites?)

My own knowledge only goes as far about this, so I would
recommend you
to ask in microsoft.sqlserver.public.replication.
--
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp

Thanks for your reply. probably I wrote it in a wrong way.
There is no permenant connectivity between the two locations. Whenever
mself / management decides to Synch. the data I connect using ISDN
connection , perform export / Import Using BCP at both the sides and
then run SQL Script to push the incremental data inside the database.
Before going to the database it comes to a buffer database FROM text
files.
regards
Rohit

--
Posted using the http://www.dbforumz.com interface, at author's request
Articles individually checked for conformance to usenet standards
Topic URL: http://www.dbforumz.com/General-Disc...ict236236.html
Visit Topic URL to contact author (reg. req'd). Report abuse: http://www.dbforumz.com/eform.php?p=821317

[Erland Sommarskog]

Rohit (Us************@dbForumz.com) writes:

Thanks for your reply. probably I wrote it in a wrong way.
There is no permenant connectivity between the two locations. Whenever
mself / management decides to Synch. the data I connect using ISDN
connection , perform export / Import Using BCP at both the sides and
then run SQL Script to push the incremental data inside the database.
Before going to the database it comes to a buffer database FROM text
files.

OK. As I said, merge replication could be worth looking into. But I know
too little of merge replication as well as your application to say for
sure that it is a good idea.
--
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp