Thanks for the info guys.  This makes me less nervous about using SQLCE in
this context.

SqlMetal is definitely required for SQLCE, but if you're generating DBML
then you can still use the design surface in VS (just have to generate the
DBML manually first).  I'm happy to use LINQ to SQL here as there is no need
to send the data across tiers, and I've had a few bad experiences in the
past with refactoring strongly typed datasets (probably my fault for not
quite fully understanding the details).

Cheers.

On Thu, Aug 26, 2010 at 8:18 PM, Greg Keogh <g...@mira.net> wrote:

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

Reply via email to