Converting to use replication

I have a DB running under SQL 2005. I would like to enable the database for
replication to offline clients (SQLExpress) and SQL Server 2005 Compact
Edition.
Will converting the primary keys of the database to use GUID's be sufficient
to enable the replication to work property.? They are currently integers.
No, don't do this. Replication will add its own GUID key.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Nick Zdunic" <NickZdunic@.discussions.microsoft.com> wrote in message
news:A04F975C-AC8F-4FDB-A6D4-030C21392DFF@.microsoft.com...
>I have a DB running under SQL 2005. I would like to enable the database
>for
> replication to offline clients (SQLExpress) and SQL Server 2005 Compact
> Edition.
> Will converting the primary keys of the database to use GUID's be
> sufficient
> to enable the replication to work property.? They are currently integers.
|||I know that it does this, but my keys are autonumber fields, so wouldn't it
be better to convert them to GUIDs so that clashes don't occur later on.
Because the fields are GUIDs SQL server shouldn't need to add GUIDs - or
will this still occur even when GUIDs are already present?
"Hilary Cotter" wrote:

> No, don't do this. Replication will add its own GUID key.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
>
> "Nick Zdunic" <NickZdunic@.discussions.microsoft.com> wrote in message
> news:A04F975C-AC8F-4FDB-A6D4-030C21392DFF@.microsoft.com...
>
>
|||Either consider automatic identity range management or use different seeds
on either side, i.e. even on one side, odd on another.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Nick Zdunic" <NickZdunic@.discussions.microsoft.com> wrote in message
news:EEEEBE0A-22E9-432A-A2AF-98EF18806B7A@.microsoft.com...[vbcol=seagreen]
>I know that it does this, but my keys are autonumber fields, so wouldn't it
> be better to convert them to GUIDs so that clashes don't occur later on.
> Because the fields are GUIDs SQL server shouldn't need to add GUIDs - or
> will this still occur even when GUIDs are already present?
> "Hilary Cotter" wrote:
|||Might still go with GUIDs - as the number of clients could vary so it will be
easier to manage.
So will using GUIDs stop the extra GUID being added by SQL Server?
"Hilary Cotter" wrote:

> Either consider automatic identity range management or use different seeds
> on either side, i.e. even on one side, odd on another.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
>
> "Nick Zdunic" <NickZdunic@.discussions.microsoft.com> wrote in message
> news:EEEEBE0A-22E9-432A-A2AF-98EF18806B7A@.microsoft.com...
>
>
|||You can add your own GUID field and call it what you want. Replication
needs a uniqueidentifier field with the ROWGUIDCOL property set. If it
finds an existing one it will use that instead of creating a new one.
Just remember to set the field default to (newid()).
I agree with the advice not to set your primary key to a GUID. You will
run into performance problems when the table grows. Searching an integer
index is much faster than searching an GUID index. Auto identity
requires management, but it is definately the way to go.
Nick Zdunic wrote:[vbcol=seagreen]
> Might still go with GUIDs - as the number of clients could vary so it will be
> easier to manage.
> So will using GUIDs stop the extra GUID being added by SQL Server?
> "Hilary Cotter" wrote:
|||Int's will be faster, but with more than 5 replicas and maybe even 10 to 50
managing autonumber fields would be a nightmare.
"JE" wrote:

> You can add your own GUID field and call it what you want. Replication
> needs a uniqueidentifier field with the ROWGUIDCOL property set. If it
> finds an existing one it will use that instead of creating a new one.
> Just remember to set the field default to (newid()).
> I agree with the advice not to set your primary key to a GUID. You will
> run into performance problems when the table grows. Searching an integer
> index is much faster than searching an GUID index. Auto identity
> requires management, but it is definately the way to go.
>
> Nick Zdunic wrote:
>