The data type is called uniqueidentifier

Greg

On Thu, Feb 2, 2012 at 11:01 AM, Kirsten Greed <kirst...@jobtalk.com.au>wrote:

> ** **
>
> I did find a mention on stack overflow that suggests using a separate sync
> key. It doesn’t mention GUIDS
> http://stackoverflow.com/questions/7184372/how-do-you-sync-databases-using-ms-sync-framework-when-tables-are-using-identity
> ****
>
> What data type would you use to store guids in the database?****
>
> ** **
>
> ** **
>   ------------------------------
>
> *From:* ozdotnet-boun...@ozdotnet.com [mailto:
> ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Greg Kennedy
> *Sent:* Thursday, 2 February 2012 11:08 AM
> *To:* ozDotNet
> *Subject:* Re: Making an application that uses identity keys
> occassionallyconnected****
>
> ** **
>
> I think the sync framework will crack a fruity if the Guid is not the PK.*
> ***
>
> On Thu, Feb 2, 2012 at 8:50 AM, Greg Keogh <g...@mira.net> wrote:****
>
> Kirsten has lots of tables already created with traditional PK IDENTITY
> columns, so I’m guessing that converting the PKs would be a nightmare.
> Perhaps a compromise is the answer: add an indexed Guid column to those
> tables that might find it useful in sync processing. That Guid is
> effectively “stamped” onto the row and never changes even if the ****INT
> PK**** does. I did this years ago to some of my own tables and they’re
> still in use and the Guids are used by external applications to reliably
> and unambiguously find rows.****
>
>  ****
>
> However, can Sync Framework make use of Guid columns that are not the
> actual PK?****
>
>  ****
>
> Greg****
>
>  ****
>
> ** **
>

Reply via email to