John,

In this world, there are followers and there are pioneers. Your comments are consistent with one who is the former.

First - a FACT - few developers who wrote SQL stored procs are overly impressed with LINQ to SQL, and most don't have plans to use LINQ to SQL instead of stored procs. If you don't believe me, go raise the issue on the MS News SQL Server newsgroup, or up on SQL Server Central, or SSWUG, or go ask some SQL MVPs. Those interested in things either directly or indirectly related to LINQ are encouraged by other aspects, like querying objects or XML, as well as the new entity FW.

If MS really wants everyone to use LINQ to SQL, why do they continue to add t-sql language enhancements in SQL '08 that are best leveraged in stored procs??

I don't recall you providing anything that meaningful on this issue. If you honestly want a list of about a dozen different instances where generated LINQ to SQL code is a far cry from what you'd write on your own, I'll give them to you - though given history, I doubt it would do any good.

Second, torturous? hmmmm....First, very few installations need to set non-NULL data to NULL. So the full solution I previously provided can be cut in half if you don't need to set non-NULLs to NULL. Most posts I've found on this issue utilized a 2nd set of parameters to differentiate between an explicit and an implicit NULL, thereby complicating the API to the SP. I came up with something that reduced the # of parameters from what has often been used to solve the problem. I'd like to know why you consider it 'torturous' (maybe you and the enigmatic Australian 'RVBoy' can compare notes on transporation analogies?) <s>


Third, from ADO.NET 1.1 to ADO.NET 2.0, there were enhancements (the indexing engine in ADO.NET was re-written) so that many dataset operations were faster. But we're now up to two full versions since the "personal list" statement (which you seem to refer to, more often than he does), and auto-spanning isn't in.

I personally don't care if it (auto-spanning) gets in or not, so long as it doesn't adversely affect the core ADO.NET engine. But I will tell you once again - I have yet to find ONE .NET developer outside this forum who thinks it's a good idea. I've even played devil's advocate with people on it, and they honestly thought I was smoking crack. Once again, if you don't believe me, go hit some of the .NET forums and newsgroups and raise the issue.