You have to use an intermediary table.

You mentioned queries returning objects that do not match the query. It’s a shame that MS haven’t taken advantage of LINQ to solve this (or at least, partially solve it). They should be able to run the criteria again in memory (after the SQL) to strip out the non-matching objects. I tried to describe this here http://dotnet.agilekiwi.com/blog/index.html (under the heading “option 4″), but unfortunately the post got a little too wordy! :-)

I’m afraid I don’t have any more specific information right now – I hope Microsoft’s PAG will produce a best-practices document on using LINQ to SQL in web environments.

[)amien

But the thing is what about the deployment problems it can cause?everything is getting coupled with the datacontext object, will that bring more problem than the solution in a transactionless(transaction free) web enviroment?

An interesting approach to optimistic locking – most people use version number fields or some derivative. There’s a problem with their approach to this – CLOB and BLOB columns and partitioning. You can’t use this technique on tables with large object columns, and any vertical partitioning will make this approach very inefficient. The latter is perhaps less common but BLOBs certainly aren’t.

Maybe they just ignore BLOB columns and expect you to put an always-updated field in there (like a timestamp or version number) – although that kind of defeats the object since you might as well just use that one field in that case.

One thing that often irritates me about MS frameworks is that they a) reinvent
the wheel, b) always seem to be in beta, unfinished, or about to be replaced
with a new interface-breaking version. If you want to make something stable you
want something that’s been around in the real world for a while and had the
kinks ironed out already. LINQ looks nice in theory but I’m willing to bet it
will have plenty of problems in the short term. I suspect their inability to stick to one framework / interface is to do with their background as a product company that constantly needs to push out something new and buzzwordy for people to buy. J2EE might have become less sexy these days, but at least it has solutions for things like this which have been used and proven over many years, without being end-of-lined all the time to make way for the next sexy acronym. Stablility isn’t sexy, but I know which I prefer when it comes to writing production code.