Hi ,
I am new in replication area . I have created a merge replication . The
tables which is present in source table has identity key, after creating
replication , I am able to add duplicate values in source as well as
destinations table having same identity values .
Secondly , When new table having identity values are added in article e.g
test1 ,Current Identity seed of test1 in different in destination database
.. I want to synchronise the data in 2 database . ie. when I am inserting
values in Test 1 table on DB1, identity seed should be taken correct seed
automatically and vice versa for destination table . Most of our tables are
containing identity keys , and all reports are based on that key .
Also ,pls let me know is there any helpful articles which simulatiing same
kind of problem.
Pls help me in this regard.
Regards,
Swati
Swati,
when you're ading the table, have a look at the table properties (this is an
elipsis button next to the table). There is a tab for identities. You can
select automatic range management here - ideally select a big enough range
so that there will not be any need to get another. This will ensure no
overlaps.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
Showing posts with label area. Show all posts
Showing posts with label area. Show all posts
Wednesday, March 28, 2012
Friday, March 9, 2012
Merge replication ExchangeType question.
I have an application that will have very limited functionality in a
disconnected mode. I plan on recording operations in the one area of our
application where we allow inserts in disconnected mode and updating the
publisher through custom code that basically replays what the user did in
disconnected mode. Then using merge replication in dowload only mode to pull
any updates back to the subscriber.
My question is do I need to delete the rows that were inserted in
disconnected mode on the subscriber before starting the merge process. I am
concerned that the publisher will see the inserts from the custom code and
attempt an insert on the subscriber even though the row already exists there.
Is merge replication smart enough (in download only mode) to delete the rows
that were added in disconnected mode on the subscriber (since they don't
exist on the publisher) before inserting the rows from the publisher? To put
it another way, does merge replication try to completely synchronize data on
both the subscriber and the publisher by forcing the subscriber to have the
same data as the publisher in download only mode?
I think my last post may have been confusing.
Can the data be modified or inserted on the subscriber but then the
subscriber be forced to synchronize completely with the publisher's copy of
the database. In other words, any data created on the subscriber is purged
during the merge process instead inserted into the publisher?
|||I'd have to test, but I think you'll have to remove these rows yourself. You
can identify them by matching the guids in msmerge_contents, and this could
be an extra step in the merge agent's job.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Yes, you will need to delete the rows on the subscriber, otherwise you will
get a conflict when the row moves from the publisher to the subscriber.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"mspradley" <mspradley@.discussions.microsoft.com> wrote in message
news:8F9DE6A4-B8F1-45D3-843C-4EA6F5F6BF94@.microsoft.com...
> I have an application that will have very limited functionality in a
> disconnected mode. I plan on recording operations in the one area of our
> application where we allow inserts in disconnected mode and updating the
> publisher through custom code that basically replays what the user did in
> disconnected mode. Then using merge replication in dowload only mode to
pull
> any updates back to the subscriber.
> My question is do I need to delete the rows that were inserted in
> disconnected mode on the subscriber before starting the merge process. I
am
> concerned that the publisher will see the inserts from the custom code and
> attempt an insert on the subscriber even though the row already exists
there.
> Is merge replication smart enough (in download only mode) to delete the
rows
> that were added in disconnected mode on the subscriber (since they don't
> exist on the publisher) before inserting the rows from the publisher? To
put
> it another way, does merge replication try to completely synchronize data
on
> both the subscriber and the publisher by forcing the subscriber to have
the
> same data as the publisher in download only mode?
disconnected mode. I plan on recording operations in the one area of our
application where we allow inserts in disconnected mode and updating the
publisher through custom code that basically replays what the user did in
disconnected mode. Then using merge replication in dowload only mode to pull
any updates back to the subscriber.
My question is do I need to delete the rows that were inserted in
disconnected mode on the subscriber before starting the merge process. I am
concerned that the publisher will see the inserts from the custom code and
attempt an insert on the subscriber even though the row already exists there.
Is merge replication smart enough (in download only mode) to delete the rows
that were added in disconnected mode on the subscriber (since they don't
exist on the publisher) before inserting the rows from the publisher? To put
it another way, does merge replication try to completely synchronize data on
both the subscriber and the publisher by forcing the subscriber to have the
same data as the publisher in download only mode?
I think my last post may have been confusing.
Can the data be modified or inserted on the subscriber but then the
subscriber be forced to synchronize completely with the publisher's copy of
the database. In other words, any data created on the subscriber is purged
during the merge process instead inserted into the publisher?
|||I'd have to test, but I think you'll have to remove these rows yourself. You
can identify them by matching the guids in msmerge_contents, and this could
be an extra step in the merge agent's job.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Yes, you will need to delete the rows on the subscriber, otherwise you will
get a conflict when the row moves from the publisher to the subscriber.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"mspradley" <mspradley@.discussions.microsoft.com> wrote in message
news:8F9DE6A4-B8F1-45D3-843C-4EA6F5F6BF94@.microsoft.com...
> I have an application that will have very limited functionality in a
> disconnected mode. I plan on recording operations in the one area of our
> application where we allow inserts in disconnected mode and updating the
> publisher through custom code that basically replays what the user did in
> disconnected mode. Then using merge replication in dowload only mode to
pull
> any updates back to the subscriber.
> My question is do I need to delete the rows that were inserted in
> disconnected mode on the subscriber before starting the merge process. I
am
> concerned that the publisher will see the inserts from the custom code and
> attempt an insert on the subscriber even though the row already exists
there.
> Is merge replication smart enough (in download only mode) to delete the
rows
> that were added in disconnected mode on the subscriber (since they don't
> exist on the publisher) before inserting the rows from the publisher? To
put
> it another way, does merge replication try to completely synchronize data
on
> both the subscriber and the publisher by forcing the subscriber to have
the
> same data as the publisher in download only mode?
Labels:
adisconnected,
application,
area,
database,
exchangetype,
functionality,
limited,
merge,
microsoft,
mode,
mysql,
operations,
oracle,
plan,
recording,
replication,
server,
sql
Subscribe to:
Posts (Atom)