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

Very cool. Thanks for sharing that Viv. I'm still playing with Linq-to-sql because we haven't needed it for much so far, so it's mostly just research to learn and I missed that capability completely so far.