>>>The major downside I see with Linq-to-Sql is not being able to use Stored Procedures (assuming I'm correct in this assumption).
>>
>>Not correct :-} You can just drop stored procedures on the design surface and it will generate the relevant ExecuteMethodCall()'s
>
Hi,

>OK, I didn't really know (guess I should shut up then <g>) ...

Lots of times I've said 'I don't use such-and-such' because it can't do so-and-so' only to be told that it can. And if I'd never made the statement in the first place I might neve have found out. :-}

>could you explain how that fits into LINQ's SELECT syntax?

The designer basically creates a method (with default name the same as the SPROC name) on the DataContext with the method taking that same parameters that are required by the SPROC. So you don't use a select to retreive. More like:

List<things> = DataContext.ProcedureName(param1, param2);

This link describes better and in more detail:http://weblogs.asp.net/scottgu/archive/2007/08/16/linq-to-sql-part-6-retrieving-data-using-stored-procedures.aspx

Best,
Viv