June 21, 2013 at 6:44 am
No doubt it's too late to change this, but have you thought about using NewId rather than identity as your (nonclustered) PK in the various tables?
As far as I know, this is guaranteed to be unique across the distributed instances and could therefore become the 'permanent' PK for a row, regardless of database.
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
June 21, 2013 at 7:00 am
Phil Parkin (6/21/2013)
No doubt it's too late to change this, but have you thought about using NewId rather than identity as your (nonclustered) PK in the various tables?As far as I know, this is guaranteed to be unique across the distributed instances and could therefore become the 'permanent' PK for a row, regardless of database.
fwiw, I agree with you. I think using guid pks with NewId() for a default value is probably the best way to go. If this were the case I should be able to select all the data for a person from one db and just save it to another db. From what I understand guids are the way to go when consolidating data from multiple dbs.
For some reason our team is really trying to avoid guids as pks. In general we have some bad experiences with guids due to work done in the past where guids were used but were not necessary. I think that's made everyone here gun shy about using them.
June 21, 2013 at 7:40 am
Well, if I were you I would suggest it, so that when the pain of maintaining your IDENTITY solution becomes too much to bear, you can always be the smart one who says: I told you so 😉
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
Viewing 3 posts - 16 through 17 (of 17 total)
You must be logged in to reply to this topic. Login to reply