Hi Greg ,Greg ,Greg, David, David and Heinrich I am worried about the performance issues this could create. Some of my queries go 5 tables deep or more, up till now an int primary key has seemed like the best performance option.
The idea of adding a sync only guid key is appealing to me however I am worried by Greg Kennedy's thoughts that it will crack a fruity. Does anyone have more info about this? Should I just run some experiments? Thanks Kirsten -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Greg Shaw Sent: Friday, 3 February 2012 2:46 PM To: ozDotNet Subject: Re: Making an application that uses identity keysoccassionallyconnected Any chance you can use a compound key? Where the client that creates the record has a fixed key and an auto increment key. Together the keys would be unique. You can also tell where the record was created. Greg. On Thu, 2012-02-02 at 11:03 +1000, Greg Kennedy wrote: > The data type is called uniqueidentifier > > > Greg > > On Thu, Feb 2, 2012 at 11:01 AM, Kirsten Greed > <[email protected]> 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-m s-sync-framework-when-tables-are-using-identity > > What data type would you use to store guids in the database? > > > > > > > > ______________________________________________________________ > From:[email protected] > [mailto:[email protected]] 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 <[email protected]> > 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 > > > > > > > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 6777 (20120108) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
