From: Michael C on
"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
"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
"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
"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
"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.


First  |  Prev  |  Next  |  Last
Pages: 5 6 7 8 9 10 11 12 13 14 15 16 17
Prev: Sql Server on VMWare
Next: AdventureWorks database