Prev: Sql Server on VMWare
Next: AdventureWorks database
From: Michael C on 6 Dec 2009 20:06 "Michael Coles" <michaelcoAToptonlineDOTnet> wrote in message > I'm not understanding how your example proves your point. Your example > proves (assuming a few things about your code, that is) that ADO.NET can > handle TVPs, which is what Erland has already stated a few times. Is the > point you're trying to make that LINQ to Objects does support SQL Server > Table-Valued Parameters? I'd love to see that code sample sometime! My point is that Linq can return the appropriate data to pass a TVP. > The "code generator" is not the *only* limitation. You can generate all > the code in the world, incorporating all kinds of features, but it does > you no good if the guts of your provider can't take advantage to make the > new features actually work. This is a provider limitation. The LINQ to > SQL provider, and all LINQ providers that I know of, do not have the > capability to handle SqlDbType.Structured data. Actually yes this is true. I was mistaken about the details of linq-to-sql. I think it is a load of rubbish so I have not used it much. Michael
From: Michael C on 6 Dec 2009 20:07 "Michael Coles" <michaelcoAToptonlineDOTnet> wrote in message news:uc8uEMQdKHA.744(a)TK2MSFTNGP05.phx.gbl... > Come to think of it, and I have to ask this based on your comments in this > thread, do you actually know what a "Table-Valued Parameter" is? I'm not even going to dignify that with an answer, oops, I just did ;-) Michael
From: Michael Coles on 6 Dec 2009 21:23 "Michael C" <mike(a)nospam.com> wrote in message news:u9LOGmtdKHA.6096(a)TK2MSFTNGP02.phx.gbl... > "Michael Coles" <michaelcoAToptonlineDOTnet> wrote in message >> I'm not understanding how your example proves your point. Your example >> proves (assuming a few things about your code, that is) that ADO.NET can >> handle TVPs, which is what Erland has already stated a few times. Is the >> point you're trying to make that LINQ to Objects does support SQL Server >> Table-Valued Parameters? I'd love to see that code sample sometime! > > My point is that Linq can return the appropriate data to pass a TVP. .... .NET DataTables, IEnumerable objects and data readers? I would hope LINQ can return some (if not all) of these types of objects or it wouldn't be of much use. >> The "code generator" is not the *only* limitation. You can generate all >> the code in the world, incorporating all kinds of features, but it does >> you no good if the guts of your provider can't take advantage to make the >> new features actually work. This is a provider limitation. The LINQ to >> SQL provider, and all LINQ providers that I know of, do not have the >> capability to handle SqlDbType.Structured data. > > Actually yes this is true. I was mistaken about the details of > linq-to-sql. I think it is a load of rubbish so I have not used it much. It's really for people who want a lightweight .NET OR/M solution for SQL Server, but I have to admit I haven't found much use for it myself. -- Thanks Michael Coles SQL Server MVP Author, "Expert SQL Server 2008 Encryption" (http://www.apress.com/book/view/1430224649) ----------------
From: Michael C on 6 Dec 2009 23:28 "Michael Coles" <admin(a)geocodenet.com> wrote in message news:0C6BC4F5-1061-4057-829E- > ... .NET DataTables, IEnumerable objects and data readers? I would hope > LINQ can return some (if not all) of these types of objects or it wouldn't > be of much use. I did say it could do it easily and it was trvial. :-) > It's really for people who want a lightweight .NET OR/M solution for SQL > Server, but I have to admit I haven't found much use for it myself. I guess I don't see an issue with it except for the way it translates linq into sql code. I can't imagine why we'd want to go to so much trouble to have linq translated into sql. Surely it would just make writing optimised sql more difficult. This is one of the reasons I want a native linq database, then we'd have a really good reason to use linq :-) Michael
From: Michael Coles on 7 Dec 2009 09:56
"Michael C" <mike(a)nospam.com> wrote in message news:OooK9WvdKHA.2596(a)TK2MSFTNGP04.phx.gbl... > > I did say it could do it easily and it was trvial. :-) Unfortunately the ability to return a .NET DataTable in .NET code != SQL Server TVP Support > I guess I don't see an issue with it except for the way it translates linq > into sql code. I can't imagine why we'd want to go to so much trouble to > have linq translated into sql. Surely it would just make writing optimised > sql more difficult. This is one of the reasons I want a native linq > database, then we'd have a really good reason to use linq :-) At this point I have no definition for a "native linq database". It sounds like a marketing slogan more than a real enterprise DBMS. So far we've seen a wish list of DBMS and database language features, but not a foundation for an enterprise DBMS. BTW, the MS push appears to be to get people using EF instead of LINQ right now. |