New to merge replication - simple scenario......

[Robin Tucker]

I have a product that sits on a main server and wish to implement
functionality to allow salesmen to come along, pick up a snapshot of the
database, go away and maybe modify/add to it and then come back and
"synchronis e" their data. I'm reading up on Merge Replication for this
purpose. But anyway, I created a publisher on my server and it went away
and generated a "rowguid" column on all of my tables (my tables all have an
Identity column key field). Now of course my "Inserts" no longer work, as
they expect a GUID. I would have expected SQL Server to automatically
generate a guid for new inserts (in a similar way to it's TIMESTAMP), but it
appears it doesn't, despite the fact I have "(newid())" as the default for
the column. It always inserts the same value:
{00000000-0000-0000-0000-000000000000}.

So, back to basics, now I have a guid field for each record, how do I manage
inserts?

Thanks.

[Simon Hayes]

"Robin Tucker" <id************ *************@r eallyidont.com> wrote in
message news:d7******** ***********@new s.demon.co.uk.. .

I have a product that sits on a main server and wish to implement
functionality to allow salesmen to come along, pick up a snapshot of the
database, go away and maybe modify/add to it and then come back and
"synchronis e" their data. I'm reading up on Merge Replication for this
purpose. But anyway, I created a publisher on my server and it went away
and generated a "rowguid" column on all of my tables (my tables all have
an Identity column key field). Now of course my "Inserts" no longer work,
as they expect a GUID. I would have expected SQL Server to automatically
generate a guid for new inserts (in a similar way to it's TIMESTAMP), but
it appears it doesn't, despite the fact I have "(newid())" as the default
for the column. It always inserts the same value:
{00000000-0000-0000-0000-000000000000}.

So, back to basics, now I have a guid field for each record, how do I
manage inserts?

Thanks.

Good practice is to explicitly name the target columns in all your INSERTs,
eg:

insert into dbo.MyTable (col1, col2)
select col1, col2
from dbo.MyOtherTabl e

If you do this, then there's no problem - your INSERT works as usual, and
you can ignore the uniqueidentifie r column completely. Since there's a
default on it, there's no need to include it in the INSERT.

Simon

[Robin Tucker]

So am I right in thinking that the unique GUID will be created on the field
when data is pushed or pulled - as I say, the newid() seems to produce a
zero'd GUID. I was thinking I am responsible for maintaining the uniqueness
of this ID, but this can't be right.
"Simon Hayes" <sq*@hayes.ch > wrote in message
news:42******** **@news.bluewin .ch...

"Robin Tucker" <id************ *************@r eallyidont.com> wrote in
message news:d7******** ***********@new s.demon.co.uk.. .

I have a product that sits on a main server and wish to implement
functionality to allow salesmen to come along, pick up a snapshot of the
database, go away and maybe modify/add to it and then come back and
"synchronis e" their data. I'm reading up on Merge Replication for this
purpose. But anyway, I created a publisher on my server and it went
away and generated a "rowguid" column on all of my tables (my tables all
have an Identity column key field). Now of course my "Inserts" no longer
work, as they expect a GUID. I would have expected SQL Server to
automatically generate a guid for new inserts (in a similar way to it's
TIMESTAMP), but it appears it doesn't, despite the fact I have
"(newid())" as the default for the column. It always inserts the same
value: {00000000-0000-0000-0000-000000000000}.

So, back to basics, now I have a guid field for each record, how do I
manage inserts?

Thanks.

Good practice is to explicitly name the target columns in all your
INSERTs, eg:

insert into dbo.MyTable (col1, col2)
select col1, col2
from dbo.MyOtherTabl e

If you do this, then there's no problem - your INSERT works as usual, and
you can ignore the uniqueidentifie r column completely. Since there's a
default on it, there's no need to include it in the INSERT.

Simon

[Simon Hayes]

"Robin Tucker" <id************ *************@r eallyidont.com> wrote in
message news:d7******** ***********@new s.demon.co.uk.. .

So am I right in thinking that the unique GUID will be created on the
field when data is pushed or pulled - as I say, the newid() seems to
produce a zero'd GUID. I was thinking I am responsible for maintaining
the uniqueness of this ID, but this can't be right.

<snip>

As far as I'm aware, in the case of uniqueidentifie r columns added to
support merge replication, it's the replication process that maintains these
values. But I'm not at all an expert in replication, so you might want to
consider posting to microsoft.publi c.sqlserver.rep lication if you need more
details.

Simon