Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
dcwebman
Starting Member
11 Posts |
 Posted - 2009-09-16 : 15:57:34
|
| We have a few servers that we were using SQL 2000 to push data to with merge replication and didn't need data back. In the meantime our local server went to SQL 2005 and a new subscriber got set up with SQL 2005 and we set up the merge again. I didn't do it but I heard some things changed between the two regarding identity fields.Anyway, for some unknown reason to us so far, the tables on the subscriber that have identity fields are getting seeded really high. For example, on the source the current identity is 1 and the subscriber is 24002. Some tables that had a higher identity like 17363 on the source suddenly were 20017363. Next time replication ran and a new record entered it got entered as 40017364.Any idea what we need to change in the SQL 2005 replication settings to avoid this?FYI, I don't have all the answers as to setup so I may have to check with another before I get back if someone has a question.Thanks for any help!JeffEDIT: I was just informed that with the merge replication we are indeed getting data back from the subscriber so the publisher and subscriber databases are supposed to be identical. |
|
|
krishnarajeesh
Yak Posting Veteran
67 Posts |
Posted - 2009-11-04 : 02:50:25
|
| For merge replication , if we select auto manage identity range, system will automatically control the range.In this case , its quite obvious that the identity range may be a greater value , depends on the existing identity values. You do not have to worry about identity range if we make it auto manage, else we have to make it manaul & specify a range. Say odd numbers in the source & even numbers in the destination.Thanks,Krishnawww.SQLServer.in |
 |
|
|
dcwebman
Starting Member
11 Posts |
Posted - 2009-11-04 : 06:40:22
|
| Thanks for the reply. We did have it at auto manage but the problem was that some various non-DB code never expected identity numbers greater than 32768 so that started breaking. It would require a lot of rewrites to try and find all those areas. We're still trying to find a solution and not exactly sure what that would be. |
|
|
|
krishnarajeesh
Yak Posting Veteran
67 Posts |
Posted - 2009-11-04 : 06:51:50
|
| ok, if there is a problem exists you may can remove the subscription, make sure the same data is available in both ends...may be through export/import or queries. And then recreate the subscrption with No Initialize. Also make sure a fresh identity range is mentioned.Thanks,Krishnawww.SQLServer.in |
|
|
|
|
|
|
|
|
Merge with identity fields changing