Are you likely to be replicating information back and forth between SQL Server and SQLite?
Am currently investigating using some variation of a GUID to enable good replicability between SQL Server and SQLite when using Microsoft's open source Sync Framework 4.0 - to replace the previously used IDENTITY columns. Currently leaning towards CombIT (a GUID with built-in date and time) as it performs well in larger datasets (a 5% performance hit with large upside on the replication front). http://www.informit.com/articles/printerfriendly.aspx?p=25862 http://www.codinghorror.com/blog/2007/03/primary-keys-ids-versus-guids.html If replication between devices and SQL Server is likely to come up then this might be worth considering (lateral thinking)....but if they are going to live isolated then perhaps someone else has an answer. Andrew ---------------------------------------- From: "Greg Keogh" <g...@mira.net> Sent: Tuesday, January 22, 2013 9:20 PM To: "ozDotNet" <ozdotnet@ozdotnet.com> Subject: SQLite and SQL Server schemas Folks, I was considering being able to swap SQLite and SQL Server/Compact/Azure as the backend of my app. I use POCOs as the entities and I can generate multiple EDXMs for the databases and load them dynamically a runtime. It's a bit tricky to keep everything "neutral" and abstract the database away, but it was looking feasible as a good cooding exercise. Then I suddenly reaslised that the POCOs aren't "neutral" because the SQLite IDENTITY columns are 64-bit and the SQL ones are 32-bit. I ran a diff on the POCOs and was suddenly reminded of this difference. Dammit! So, do I make all the IDENTITY columns in the SQL databases 64-bit to match (if that's possible), or perhaps there is some other lateral thinking trick I'm missing. Having a completely replaceable database is a lovely thing to have, but tricker in practise than I initially thought with EF5 and POCOs. Has anyone attempted this sort of thing before? Greg
