Hi Kirsten, I found the tooling for the sync framework to be very flakey. Google searches (support) can lead you on wild goose chases because it's all old and can be irrelevant. Framework versions 1.0 2.1 4.0 CTP combined with several different sql compact versions and azure all mixed together...
I researched the options about 12 months ago and ended up going ahead with the occasionally connected app consisting of a ClickOnce WPF client (tablet), SyncFx2.1, which uses SQLCompact 3.5, and EF connecting back to the SQL server db. I had the extra complication of having to sync legacy data from an ancient financial database that didn't even have PKs although I added them on. These PKs were incrementing integers however the tables that they synch'd on were read only. The system works now however db alterations do cause issues and consequent resynching of the data. Changing the EF diagrams is painful as there are manual associations set up with the legacy data. This probably won't affect you however. I guess I am disillusioned somewhat by the appearance that MS had given up on the framework, as 4.0 has been in CTP for over a year now and wish that I had continued to look into writing an offline HTML5 app with some other database option. Run some experiments but I don't know that changing from an int to a guid will have much of a performance impact, and if that's the only showstopper then it might be worth the effort of changing over. Or... look into some other solution of synching the data with jquery, indexeddb, some sort of syncing framework... There's surely a market around for someone to come up with a robust synching solution now (12 months on). Good luck, Greg. On Sat, Feb 4, 2012 at 8:09 AM, Kirsten Greed <kirst...@jobtalk.com.au>wrote: > 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: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] > 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 > > <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-m > s-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 > > > > > > > > > > > > > > > > > > > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature > database 6777 (20120108) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > >
