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-Dis...pict236236.html
Visit Topic URL to contact author (reg. req'd). Report abuse: http://www.dbforumz.com/eform.php?p=819975Rohit (UseLinkToEmail@.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, esquel@.sommarskog.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||"" wrote:
> Rohit (UseLinkToEmail@.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, esquel@.sommarskog.se
> Books Online for SQL Server SP3 at
> http://www.microsoft.com/sql/techin.../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-Dis...pict236236.html
Visit Topic URL to contact author (reg. req'd). Report abuse: http://www.dbforumz.com/eform.php?p=821317|||Rohit (UseLinkToEmail@.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, esquel@.sommarskog.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp
