Showing posts with label happening. Show all posts
Showing posts with label happening. Show all posts

Monday, March 26, 2012

Merge Replication Using RMO

i have done web synchronisation using RMO, where replication is happening on both ends, i want to perform one way synchronisation where a sales guy wants to update only his details to the server , and not to update the data from the server, can anybody help me on this task , the code for synchronisation i have taken out from msdn for Merge Replication using RMO programming ..

Thanks

Take a look at merge agent parameter -ExchangeType, you can set this to do upload only. Only caveat is that in SQL 2005, to download a snapshot you have to reset this to bidirectional value, which will then download the snapshot and upload/download any incremental changes.|||

-ExchangeType is not supported for Web Synchronization.

So bottom line is, you cannot do a Uploadonly or Downloadonly synchronization when using Web Synchronization. Unfortunately this is a restriction that cannot be bypassed.

|||

http://blog.csdn.net/longrujun/archive/2006/06/09/783357.aspx

|||longrujun, again, I did not see your blog post talk about this specific issue. While your step by step guide is good, it will help if you post relevant information.

Monday, March 19, 2012

Merge Replication not working after 1st Sync

I am really stuck on this, if anyone has some insight into this problem
any help would appreciated...
I'll try to explain what is happening the best I can:
We have a server running Windows Advanced Server 2000 (SP4) w/ SQL
server 2000 (SP3a) (from now on Server A). I have a publication on this
machine with dynamic filters (Changing the HOST_NAME()). The
publication is sending the snapshots to another machine (desktop
machine). The Mobile agent is in the same machine as the snapshots.
The mobile application is syncing fine when hitting Server A. The sync
is done Asynchronously.
Then we have Server B. Running Windows Server 2003 (SP1) w/ SQL 2000
(SP4), same publication w/ dynamic filter however the snapshots and the
mobile agent are in this server.
The mobile application will sync the 1st time but any subsequent syncs
will not work. I check on the Replication monitor and it tells me that
the Merge was a success but the mobile application will not execute the
download table callback, it will execute the Sync callback 5 times and
not proceed in executing the download table callback.
If I change the configuration on the mobile app to point to Server A
the sync will work just fine but, if I change it back to Server B the
sync will work once then it will stop working.
Anyone have some suggestions for troubleshooting?
Update on the situation, it turns out the Sync works fine, what's
going on is that when I sync to Server A, the average sync time is 3
minutes for 2000 rows, on Server B it's taking 45 minutes to sync 1000
rows, any ideas on how to improve/troubleshoot the situation?
I also ran profiler but I have no clue what to search for. In profiler
I couln't find any issues or unless I am not looking for the right
things. Can someone tell me what I can look for in profiler if there
is anything to look for?
Specs for Server A:
CPU: 2 Pentium 3 (550 MHz each)
RAM: 3 GBs
OS: Server 2000 Advanced (SP4)
SQL 2000 SP3
Specs for Server B:
CPU: 2 Xeon Dual-Core (2.8 GHz each)
RAM: 4 GBs
OS: Server 2003 (SP1)
SQL 2000 SP4

Monday, March 12, 2012

Merge Replication Issue. Update not happening

Hi,
We have set up merge replication between a few boxes. I make changes on one
box, replicate, and check the tables on the other box. The inserts are being
replicated, and some updates.
It appears that the updates made out of a stored proc are not being
replicated. I can manually update the table, and it will be replicated. But
when updated from the stored proc, it is not coming accrossed.
Any ideas?
Steve
More info.
sp3, no conflicts reported, after further testing, it seems one column on
one table never gets updated. Other columns that didn't, did at other times.
It is of type bit. I can manually update it and replicate, but can't have
the stored procedure update it and replicate.
"SteveInBeloit" wrote:

> Hi,
> We have set up merge replication between a few boxes. I make changes on one
> box, replicate, and check the tables on the other box. The inserts are being
> replicated, and some updates.
> It appears that the updates made out of a stored proc are not being
> replicated. I can manually update the table, and it will be replicated. But
> when updated from the stored proc, it is not coming accrossed.
> Any ideas?
> Steve
>
|||Just went to sp4, that did not help. When I do a "validate" after the
replicate, the checksum for that table fails.
"SteveInBeloit" wrote:
[vbcol=seagreen]
> More info.
> sp3, no conflicts reported, after further testing, it seems one column on
> one table never gets updated. Other columns that didn't, did at other times.
> It is of type bit. I can manually update it and replicate, but can't have
> the stored procedure update it and replicate.
>
> "SteveInBeloit" wrote:
|||More info - it is a Pull initiated at the subscriber. If I run the same
application on the Publisher, and make the updates, then replicate, the
change gets to the subscriber, just not the other way around.
"SteveInBeloit" wrote:
[vbcol=seagreen]
> Just went to sp4, that did not help. When I do a "validate" after the
> replicate, the checksum for that table fails.
> "SteveInBeloit" wrote:
|||Solved:
It was actually a delete and an insert, not an update. A record had been
written to a ##TempTable. Processing was done on that record. Then the GUID
key of that row was used to delete the row out of the real table, then and
INSERT from the temp to the real table to put it back. On that insert, I
used the same GUID key instead of letting the table NEWID get a new one. It
confused replication, having known there was a DELETE and and INSERT, but the
GUIDs the same.
"SteveInBeloit" wrote:
[vbcol=seagreen]
> More info - it is a Pull initiated at the subscriber. If I run the same
> application on the Publisher, and make the updates, then replicate, the
> change gets to the subscriber, just not the other way around.
> "SteveInBeloit" wrote:

Saturday, February 25, 2012

Merge Replication and Unique contraints

Hi,

I have a slight problem which I'm sure must be a common happening. Here's my problem.

I'm using Merge replication and I have a table the has a unique contraint on a non primary key column (the column is called [name]). The thing that goes wrong (for me) is that when a new record is added in a subscriber and a new record is added in the publisher before a synchronization and both records have the same [name] value then when the merge agent runs I get an unresolved conflict because of a unique index violation.

I've read the BOL and I'm left thinking that in order to solve this problem then I must use a custom resolver. Is this the best way of handling such a conflict? Actually if it is I'm still a little stuck as I'm not sure what I could do to help the situation inside the custom resolver anyway!!

Any help would be much appreciated.

Thanks

Graham

For handling this issue, the easy way is to also replicate that unique constraint. If both publisher and subscriber side have constraint, non-unique update won't happen before merge sync.

To do so, published article shema_option has to include "Copy unique Key Constraint", you can either through UI or SP to implement it.

Thanks

Yunjing