I have an existing merge publication and would like to convert it to
transactional with queued updates, because I think that the transactional is
probably more robust. Queued updating wasn't available in earlier versions
of SQL Server (v6.5 as I recall) when we first set up our replication. We
are using SQL Server 2000 on every subscriber.
Each table has a rowguid column that was added by the merge publication. Is
it feasible to reuse that column as the primary key for the new
transactional publication? The new publication wants to add a 2nd guid
column, but it seems unnecessary to use it, since each table already has the
rowguid. I don't want to add another guid column if it isn't necessary. I
was advised that that it would be, but am not convinced that is the case.
Thanks,
Reid
Reid,
my understanding is that guids are reused in merge if the column has
Uniqueidentifier datatype
has the ROWGUIDCOL property set, doesn't allow NULLs and has a default of
newid().
For transactional, the column must be called 'MSrepl_tran_version', doesn't
allow NULLs and has a default of newid() then it can be reused. So if you
are going from merge to transactional, and have relied on the merge process
to add the guid column, it will not be reused in transactional.
As an aside, I find merge more attractive as it has a rich set of conflict
resolvers, and the disaster recovery is straightforward as it doesn't really
use the distribution database for data transfer.
Regards,
Paul Ibison
Sunday, February 12, 2012
Convert existing merge publication to transactional with queued updates
Labels:
convert,
database,
existing,
merge,
microsoft,
mysql,
oracle,
publication,
queued,
server,
sql,
totransactional,
transactional,
updates
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment