Re: LINQ and IBM i -- SYSTEMIDOTNET

Good News Everybody!

The new search engine is LIVE!

Please report any problems to david (at) midrange.com.

Subject: Re: LINQ and IBM i
From: "Walden H. Leverich" <WaldenL@xxxxxxxxxxxxxxx>
Date: Wed, 17 Feb 2010 15:02:59 +0000
List-archive: <http://archive.midrange.com/systemidotnet>
List-help: <mailto:systemidotnet-request@midrange.com?subject=help>
List-id: ".net use with the System i" <systemidotnet.midrange.com>
List-post: <mailto:systemidotnet@midrange.com>
List-subscribe: <http://lists.midrange.com/mailman/listinfo/systemidotnet>, <mailto:systemidotnet-request@midrange.com?subject=subscribe>
List-unsubscribe: <http://lists.midrange.com/mailman/listinfo/systemidotnet>, <mailto:systemidotnet-request@midrange.com?subject=unsubscribe>

I have played with the LINQ to DataSet stuff, but to me
it didn't seem any more simple than doing regular SQL queries.

One of the claimed advantages is that you get compile-time checking of the syntax of your linq query so you can know about syntax errors earlier in the process. However, if I'm writing a sql statement I'm (probably :-) going to test is as soon as I write it by running the program, so I'll know about errors right away anyway -- so I'm with you, doesn't make sense to me.

Now linq to objects, that does make some sense, when I have a List<T> and I want some subset of that list for an action linq is great -- especially when the subset is more complicated than FindAll() can manage simply.

-Walden

Follow-Ups:

Re: LINQ and IBM i , Mike

This mailing list archive is Copyright 1997-2026 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.