You asked why I'm still a proponent of Stored procs - tell you what...fire up the latest CTP or Beta that you have, and create some linq to sql queries between related master and child tables. Then look at the generated SQL code.

Obviously I've done this before. What I (thought I) saw was injection-proof parameterized T-SQL structured for server compilation. Joins were automatic. So can you be more explicit?

If you're determined to use SPs, did you check out the ability to call SPs as a method on the DataContext?

Then you may realize what most Oracle people and a number of SQL Server people are saying - that they'd rather write their own sproc code.

That's odd, bearing in mind that you can't use Linq to SQL against Oracle yet ;-) but in any case, this is a non-sequitur. If "something" is wrong with the SQL in the beta, that doesn't lead directly to coding your own SPs. The two aren't mutually exclusive- you can even create SPs right there on the design surface if you must.