Depending on your application it might make more sense to try to
constrain the SQLite identity column to 32 bits, but if you can't do
that you should be able to use a 64bit integer for the SQL Server column:
CREATE TABLE [dbo].[ExampleTable]
(
[ExampleId] [bigint] IDENTITY(1,1) NOT NULL,
[ExampleName] nvarchar(50) NOT NULL,
CONSTRAINT [PK_ExampleTable] PRIMARY KEY CLUSTERED
(
[ExampleId] ASC
)
) ON [PRIMARY]
GO
INSERT [dbo].[ExampleTable] (ExampleName)
SELECT N'Your Data'
On 22/01/2013 9:20 PM, Greg Keogh wrote:
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
