Problem with DataTable’s ‘Select’ method

[Holly_vi]

I have a weird problem with the DataTable’s ‘Select’ method.
I use the ‘Select’ method throughout my application, and it works fine, but there is one occasion when it doesn’t work.

One of the columns in my DataTable is of type bool, named ‘X’.
At any point during the running of the application there is only one row at the most, that has this column set to true.
When I want to find out that row, I use the following statement:

DataRow[] rows = this.myDataSet.Tables["Item"].Select("[X] = 'true'");
if (rows.Length > 0)
{
	// do something wirh rows[0]
}

This works fine, but there is one occasion that I spotted where the ‘Select’ doesn’t find any row, even though I know there’s one row (with ‘Id’ 123 for instance) having column ‘X’ set to true,

In order to make sure I’m not imagining things, I added the following line above:

DataRow[] tempRows = this.myDataSet.Tables["Item"].Select("[Id] = '123'");

I started debugging and stopped at the point in the application when I have this problem.
In the watch window, I saw the following:

tempRows[“Id”] = 123
tempRows[“X”] = true
rows.Length = 0

How is that possible?
Did anyone stumble upon this problem?
When I change a value of a row’s cell do I have to use the ‘AcceptChanges’ method?

[TheCPUWizard]

Please, please please, do NOT use Select for functionallity such as this. It is totally in appropriate. The usage of Select should be completely restricted to those circumatances where you can not know the "expression" at compile time.

For ALL other conditions, please use the appropriate functionallity.

[Holly_vi]

I don’t understand your answer.
Using the ‘Select’ method is the only way I know to find rows that answer a certain condition. Is there another way?

P.S.
Sorry about the late reply.

[JonnyPoet]

What CPUWizard is talking about IMHO is that you should use
'Select' in cases like

DataRow[] rows = this.myDataSet.Tables["Item"].Select([X] =" + myBool.ToString() + ")";
if (rows.Length > 0)
{
	// do something with rows[0]
}

where myBool is different, depending on other results in your program at runtime. But IMHO you have only given an example here and 'true' isn't implemented this way, isn't it ? My question is: is X of type bool and why do you use apostrophs in your code as as much as I know this compares only strings ?

[Holly_vi]

The ‘X’ column is of type bool.
Why I use the apostrophes is in fact a good question. I think I saw it in an example somewhere.
You don’t think that this is what causes the problem, do you?

[cjard]

Please, please please, do NOT use Select for functionallity such as this. It is totally in appropriate. The usage of Select should be completely restricted to those circumatances where you can not know the "expression" at compile time.

For ALL other conditions, please use the appropriate functionallity.

I dont find a problem with it.. It is for xmpl, perfctly reasonably to use Select to pull a list of rows from a datatable where the user has elected to e.g. Print that row by ticking a box.. The underlying column is set to true, and you the coder basically want a list of rows where the ShouldPrint column is true. I do have a problem if someone is downloading a whole database into a datatable then using select instead of proper SQL queries..

OK, X as a column name sucks, but it might be obfuscated for public forum..


Holly, I think you might be able to just say:

.Select("[X]")


-> the parser requires that a boolean operation results. If youre selecting a boolean column, then you shouldnt need to compare it to another boolean to produce a boolean.. However if you find you do need to, I would try removing the apostrophes. There is a world of difference between:

true
'true'


one is a boolean, the other (in .Select() terms) is a string containing 4 characters: t, r, u and e.
If the column in question were a string column containing "true" and "false" then equating to 'true' would work

[JonnyPoet]

The ‘X’ column is of type bool.
Why I use the apostrophes is in fact a good question. I think I saw it in an example somewhere.
You don’t think that this is what causes the problem, do you?

I wouldn't bet, I would simple try but IMHO it could do a problem as apostrophes are for strings

[Holly_vi]

I tried movig the apostrophes, but it made no change.

[nabeelisnabeel]

You can use DataView and its filter mechanism for your desired task, also.

[Holly_vi]

You can use DataView and its filter mechanism for your desired task, also.

I don't understand what you mean. Can you explain?

[TheCPUWizard]

The reason I recommend against using Select in most circumstances is because of the way it works... This happens AT RUNTIME when the select statement is encountered...

1) Evaluate the Expression, and generate SOURCE CODE that will evaluate the condition in terms of elements in a row.

2) Feed that source code to the Compiler, generate MSIL

3) Load the MSIL into an AppDomain.

4) JIT Compile the code.

5) Iterate over each row passing the row to the dynamically generated code.

EXTREMELY POWERFUL....EXTREMELY COMPLEX....HIGH POSSIBILITY FOR ERRORS (failure to load appdomain,. failure to invoke compiler....)....HIGH OVERHEAD (memory AND performance).

Therefore it should only be used where you can NOT code:

List<DataRow> result = new List<DataRow>();
foreach (DataRow row in Table.Rows)
{
   if (/*write your own code here*/)
    result.Add(row);
}

As long as you can fill in the comment, then this is MUCH preferred. However if you want to allow dynamic (unpredictible) input such as:

[CustomerNumber]>1000 && [Price]<49.99
or
[CustomerState]="NY" && [Quantity]>10

Then by all means use Select.


But if you KNOW the comparision is going to involve specific fields (compared angainst unknown limits) then a coded loop is much better.

[JonnyPoet]

I don't understand what you mean. Can you explain?

Re DataView: He is talking about this
http://msdn.microsoft.com/en-us/libr....dataview.aspx
a very powerfull class

[TheCPUWizard]

Re DataView: He is talking about this
http://msdn.microsoft.com/en-us/libr....dataview.aspx
a very powerfull class

That is indeed a powerful class. and I use it somewhat often. Since it is intended for UI, the performance demands are (typically) much lower.

For example, it is generally considered acceptable if a user action returns a response in under 300mS (just less than 1/3 of a second). Anthing between "instant" and 300mS is not noticable.

Since this class would (again typically) be impacted ONCE per user update, the performance would be well within the acceptable bounds.

My earlier posts were dealing with non-UI situations (since they were classes not tied to a UI). Man many cases the code may need to run freq frequently (inside a loop perhaps), and performance can become critical.

Sincein those situations it is just as easy (if the topoligy of the selection criteria is known) to wrie the 4 lines of code, the "benefits" of the one line select turn into detriments more often than not.