I'm trying to perform a LINQ query on a DataTable object and bizarrely I am finding that performing such queries on DataTables is not straightforward. For example:
var results = from myRow in myDataTable
where results.Field("RowNo") == 1
select results;
This is not allowed. How do I get something like this working?
I'm amazed that LINQ queries are not allowed on DataTables!
dt.Rows["FirstName]
junk.. With a strongly typed table (add a DataSet type file to your project and create tables inside it in the visual designer) you just write e.g. myStronglyTpedDataset.Person.Where(p => p.FirstName == "John")
- all the magic to make it happen is already done
AsEnumerable()
call. No idea why that requires so many answers.
You can't query against the DataTable
's Rows collection, since DataRowCollection
doesn't implement IEnumerable<T>
. You need to use the AsEnumerable()
extension for DataTable
. Like so:
var results = from myRow in myDataTable.AsEnumerable()
where myRow.Field<int>("RowNo") == 1
select myRow;
And as @Keith says, you'll need to add a reference to System.Data.DataSetExtensions
AsEnumerable()
returns IEnumerable<DataRow>
. If you need to convert IEnumerable<DataRow>
to a DataTable
, use the CopyToDataTable()
extension.
Below is query with Lambda Expression,
var result = myDataTable
.AsEnumerable()
.Where(myRow => myRow.Field<int>("RowNo") == 1);
var results = from DataRow myRow in myDataTable.Rows
where (int)myRow["RowNo"] == 1
select myRow
(int)myRow["RowNo"]
with the generic form myRow.Field<int>("RowNo")
to more conveniently support nullable types.
It's not that they were deliberately not allowed on DataTables, it's just that DataTables pre-date the IQueryable and generic IEnumerable constructs on which Linq queries can be performed.
Both interfaces require some sort type-safety validation. DataTables are not strongly typed. This is the same reason why people can't query against an ArrayList, for example.
For Linq to work you need to map your results against type-safe objects and query against that instead.
As @ch00k said:
using System.Data; //needed for the extension methods to work
...
var results =
from myRow in myDataTable.Rows
where myRow.Field<int>("RowNo") == 1
select myRow; //select the thing you want, not the collection
You also need to add a project reference to System.Data.DataSetExtensions
myRow
or use Cast<DataRow>()
on Rows
. Better to use AsEnumerable()
.
System.Linq
and System.Data.DataSetExtensions
then myDataTable.Rows
returns an enumerable collection of DataRow
anyway. That might have changed, it's been a decade since I've used it.
DataSet
extensions didn't make it into .NET Core or .NET Standard, they were already outdated when I posted this answer. I really wouldn't use DataSet
in new projects, there are far better data access models, both for ease of coding and performance.
DataRowCollection
doesn't implement IEnumerable<T>
just IEnumerable
and so doesn't work with strongly typed LINQ.
I realize this has been answered a few times over, but just to offer another approach:
I like to use the .Cast<T>()
method, it helps me maintain sanity in seeing the explicit type defined and deep down I think .AsEnumerable()
calls it anyways:
var results = from myRow in myDataTable.Rows.Cast<DataRow>()
where myRow.Field<int>("RowNo") == 1 select myRow;
or
var results = myDataTable.Rows.Cast<DataRow>()
.FirstOrDefault(x => x.Field<int>("RowNo") == 1);
As noted in comments, does not require System.Data.DataSetExtensions
or any other assemblies (Reference)
var query = from p in dt.AsEnumerable()
where p.Field<string>("code") == this.txtCat.Text
select new
{
name = p.Field<string>("name"),
age= p.Field<int>("age")
};
the name and age fields are now part of the query object and can be accessed like so: Console.WriteLine(query.name);
MessageBox.Show(name)
is undefined.
Using LINQ to manipulate data in DataSet/DataTable
var results = from myRow in tblCurrentStock.AsEnumerable()
where myRow.Field<string>("item_name").ToUpper().StartsWith(tbSearchItem.Text.ToUpper())
select myRow;
DataView view = results.AsDataView();
System.Data.DataSetExtensions
.
//Create DataTable
DataTable dt= new DataTable();
dt.Columns.AddRange(new DataColumn[]
{
new DataColumn("ID",typeof(System.Int32)),
new DataColumn("Name",typeof(System.String))
});
//Fill with data
dt.Rows.Add(new Object[]{1,"Test1"});
dt.Rows.Add(new Object[]{2,"Test2"});
//Now Query DataTable with linq
//To work with linq it should required our source implement IEnumerable interface.
//But DataTable not Implement IEnumerable interface
//So we call DataTable Extension method i.e AsEnumerable() this will return EnumerableRowCollection<DataRow>
// Now Query DataTable to find Row whoes ID=1
DataRow drow = dt.AsEnumerable().Where(p=>p.Field<Int32>(0)==1).FirstOrDefault();
//
Try this simple line of query:
var result=myDataTable.AsEnumerable().Where(myRow => myRow.Field<int>("RowNo") == 1);
You can use LINQ to objects on the Rows collection, like so:
var results = from myRow in myDataTable.Rows where myRow.Field("RowNo") == 1 select myRow;
DataTable.Rows
does not implement IEnumerable
, I can't see how this query could compile.
This is a simple way that works for me and uses lambda expressions:
var results = myDataTable.Select("").FirstOrDefault(x => (int)x["RowNo"] == 1)
Then if you want a particular value:
if(results != null)
var foo = results["ColName"].ToString()
Try this
var row = (from result in dt.AsEnumerable().OrderBy( result => Guid.NewGuid()) select result).Take(3) ;
Most likely, the classes for the DataSet, DataTable and DataRow are already defined in the solution. If that's the case you won't need the DataSetExtensions reference.
Ex. DataSet class name-> CustomSet, DataRow class name-> CustomTableRow (with defined columns: RowNo, ...)
var result = from myRow in myDataTable.Rows.OfType<CustomSet.CustomTableRow>()
where myRow.RowNo == 1
select myRow;
Or (as I prefer)
var result = myDataTable.Rows.OfType<CustomSet.CustomTableRow>().Where(myRow => myRow.RowNo);
var results = from myRow in myDataTable
where results.Field<Int32>("RowNo") == 1
select results;
In my application I found that using LINQ to Datasets with the AsEnumerable() extension for DataTable as suggested in the answer was extremely slow. If you're interested in optimizing for speed, use James Newtonking's Json.Net library (http://james.newtonking.com/json/help/index.html)
// Serialize the DataTable to a json string
string serializedTable = JsonConvert.SerializeObject(myDataTable);
Jarray dataRows = Jarray.Parse(serializedTable);
// Run the LINQ query
List<JToken> results = (from row in dataRows
where (int) row["ans_key"] == 42
select row).ToList();
// If you need the results to be in a DataTable
string jsonResults = JsonConvert.SerializeObject(results);
DataTable resultsTable = JsonConvert.DeserializeObject<DataTable>(jsonResults);
System.Data.DataRow
objects. The serialized and parsed data table creates lightweight data consisting only of the column names and values of each row. When the query runs, it will load the data into memory, which for a large dataset may involve swapping. Sometimes, the overhead of several operations is less than the overhead of copying large amounts of data in and out of memory.
Example on how to achieve this provided below:
DataSet dataSet = new DataSet(); //Create a dataset
dataSet = _DataEntryDataLayer.ReadResults(); //Call to the dataLayer to return the data
//LINQ query on a DataTable
var dataList = dataSet.Tables["DataTable"]
.AsEnumerable()
.Select(i => new
{
ID = i["ID"],
Name = i["Name"]
}).ToList();
For VB.NET The code will look like this:
Dim results = From myRow In myDataTable
Where myRow.Field(Of Int32)("RowNo") = 1 Select myRow
IEnumerable<string> result = from myRow in dataTableResult.AsEnumerable()
select myRow["server"].ToString() ;
Try this...
SqlCommand cmd = new SqlCommand( "Select * from Employee",con);
SqlDataReader dr = cmd.ExecuteReader( );
DataTable dt = new DataTable( "Employee" );
dt.Load( dr );
var Data = dt.AsEnumerable( );
var names = from emp in Data select emp.Field<String>( dt.Columns[1] );
foreach( var name in names )
{
Console.WriteLine( name );
}
You can get it work elegant via linq like this:
from prod in TenMostExpensiveProducts().Tables[0].AsEnumerable()
where prod.Field<decimal>("UnitPrice") > 62.500M
select prod
Or like dynamic linq this (AsDynamic is called directly on DataSet):
TenMostExpensiveProducts().AsDynamic().Where (x => x.UnitPrice > 62.500M)
I prefer the last approach while is is the most flexible. P.S.: Don't forget to connect System.Data.DataSetExtensions.dll
reference
you can try this, but you must be sure the type of values for each Column
List<MyClass> result = myDataTable.AsEnumerable().Select(x=> new MyClass(){
Property1 = (string)x.Field<string>("ColumnName1"),
Property2 = (int)x.Field<int>("ColumnName2"),
Property3 = (bool)x.Field<bool>("ColumnName3"),
});
I propose following solution:
DataView view = new DataView(myDataTable);
view.RowFilter = "RowNo = 1";
DataTable results = view.ToTable(true);
Looking at the DataView Documentation, the first thing we can see is this:
Represents a databindable, customized view of a DataTable for sorting, filtering, searching, editing, and navigation.
What I am getting from this is that DataTable is meant to only store data and DataView is there enable us to "query" against the DataTable.
Here is how this works in this particular case:
You try to implement the SQL Statement
SELECT *
FROM myDataTable
WHERE RowNo = 1
in "DataTable language". In C# we would read it like this:
FROM myDataTable
WHERE RowNo = 1
SELECT *
which looks in C# like this:
DataView view = new DataView(myDataTable); //FROM myDataTable
view.RowFilter = "RowNo = 1"; //WHERE RowNo = 1
DataTable results = view.ToTable(true); //SELECT *
Success story sharing
using System.Data;
myDataTable.Rows
instead as @JoelFan suggested.myDataTable.Rows
is because themyRow
variable is explicitly cast toDataRow
. When it is compiled, that query is rewritten tomyDataTable.Rows.Cast<DataRow>().Where(myRow => (int)myRow["RowNo"] == 1)
. Personally, I don't find the call toAsEnumerable()
any more complicated than the call toCast<DataRow>()
. As far as I know, the performance is the same, so it's just a matter of preference.