Tim,

Thanks for all your help.

After spending several more hours looking deeper into the MM code than I care to I am sure you are right about being able to modify things. But after 40 odd years of hacking and kludging to get things to work (originally on IBM, CDC and Burroughs mainframes, more recently CodeBook 6) I have grown reluctant to do more of it. It usually involves far more overhead than I like and it eventually bites me in the butt every time.

On another note, the server generated identity issue (among other things) is resolved in SQL Server CE 4.0. That's a good thing. But CE 4 is not yet supported by MM.Net and is not yet officially supported for WinForms or WPF, so at this time SQL CE 4 would involve still more "hacking and cursing" (ref: Tommy Smothers).

Considering these points, we are reconsidering our options.

If Kevin is planning to implement EF MM entities for SQL CE (3.5 or 4) in the next year or so, we can work on the project with full SQL Server for now and implement the desktop business entities later. We don't really need to work on that part first, I just saw SQL CE as the most likely place to run into trouble, so I investigated it first. This would be our preferred option by a mile.

If Kevin doesn't plan to do EF for CE at all, but will eventually support classic business entities on SQL CE 4.0 we might consider using classic business entities.

Finally, if Kevin is not planning to support EF on SQL CE at all and is not planning to support SQL CE 4.0 for classic entities, we will need to reconsider the project architecture. We still don't want to install SQL Express on laptops and desktops for standalone use, especially not with Web distribution, and SQL Express would be a showstopper for possible future use on ultra-light mobile platforms.

I guess I'll have to ask Kevin about his plans.

Again, thanks for your help.

...Jim

>
>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