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]

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


"Robin Tucker" <idontwanttobes pammedanymore@r eallyidont.com> wrote in
message news:d7n9tc$1uu $1$8302bc10@new s.demon.co.uk.. .[color=blue]
>
> 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.
>
>
>[/color]

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]

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

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" <sql@hayes.ch > wrote in message
news:429f41fa$1 _3@news.bluewin .ch...[color=blue]
>
> "Robin Tucker" <idontwanttobes pammedanymore@r eallyidont.com> wrote in
> message news:d7n9tc$1uu $1$8302bc10@new s.demon.co.uk.. .[color=green]
>>
>> 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.
>>
>>
>>[/color]
>
> 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
>
>[/color]

[Simon Hayes]

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


"Robin Tucker" <idontwanttobes pammedanymore@r eallyidont.com> wrote in
message news:d7nge1$1p7 $1$8300dec7@new s.demon.co.uk.. .[color=blue]
> 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.
>
>[/color]

<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