Hi Matt, that warning about "not for ASP.NET development" is rather scary when you first see it. I get the feeling that there was going to be some artificial political restraints on how SQL CE could be used, but they changed their mind and that workaround was made public (or vice versa).
I've been using SQL CE as the lightweight backend of some ASP.NET apps and WCF services for over a year now, some in production use and working well. As I said earlier in the year, I quite like SQL CE, it has a kind of simple clarity and neatness that I admire. Personally, I hate bloatware, so I love liteware. So long as a single thread is accessing the CE database you'll be fine, so don't forget to keep it structured that way. Whereas LINQ to SQL generates entity classes for you (I've never used that in production), I think you'll have to get the same effect by running SqlMetal utility manually over the CE database. But I've never bothered to do that either, I just drop CE tables in the VS designer and make strongly typed DataSets which pass data up and down using classic ADO.NET techniques. People heap scorn on XSD generated DataSets, but when used with classic ADO.NET and SQL CE I reckon they make a nice "lite" solution. Incidentally, for your use, even an Access MDB might be acceptable. Sorry I haven't really answered your question, other to say I'm happy with SQL CE in web apps. I don't like LINQ to SQL as it never used to scale across tiers very well. Greg
