James,

>Tim,
>
>That would get around the initial generation issue, but there are different MM Data classes for SQL, SQL CE and SQL EF. I don't see a class for SQL CE EF.
>
>The biggest difference for EF is that the Data class references the EF Context instead of directly accessing ADO. There are also some differences for CE EF compared to standard SQL EF, for example EF for CE uses a different assembly for accessing the database and CE doesn't support stored procedures, triggers or batch commands. Also, EF CE can't automatically retrieve server generated identity columns when adding new records because EF won't use @@IDENTITY, but SCOPE_IDENTITY and IDENT_CURRENT are not implemented in CE 3.5. (I was trying to see what MM did about this last issue when I ran into the other issues.)
>
>I am skeptical that the MM EF entities generated from SQL Developer (or Express) would work for CE without some significant massaging of the generated code. Has anybody actually tried MM EF with SQL CE?
>
>I have a non-MM desktop EF app running with CE 3.5 and am quite happy with it now that I kludged something together for the identity issue and worked around the problems with ENUMs, but for my next app I need to be able to run on both SQL CE and SQL Express.
>
>...Jim
>
>>James,
>>
>>any reason you can't use SQL express for the development side? This would give you access to the BLG. I am not sure what is different about Compact so not sure why you can't use the mmDataAccessSql DA's
>>Tim

I realize this won't probably work out of the box, but I do think you could subclass the sql class and get that to work. I have not done it, but the data access classes are very well architechted and if you look through them you can probably see what you need. You do need to stick with EF classes if you are using EF I wasn't really intending otherwise. Good luck
Tim