Oh, I see the problem. There's no reason to think that the nthitem in a BindingSource's List is also going to be the nth item in a DataTable's Rows collection. This is a feature, not a bug: it lets objects that consume bound data, like the DataGridView, process the items with a loop like this:

But there's no need to despair. There are plenty of ways to get the DataRow you want.

A BindingSource's List (if you've bound it to a DataTable) doesn't contain DataRow objects. It contains DataRowView objects. The DataRowView is a simplification of DataRow that hides some of DataRow's complexities (specifically, row versions) from the BindingSource. I don't think it's possible to build robust data-bound applications without knowing about the interactions between DataRow, DataRowView, BeginEdit, and CancelEdit, but for the moment let's pretend you don't care about that.

If you want to get the DataRow which is the nth item in a BindingSource's List, you have to cast the item (which BindingSource thinks is of type System.Object) as a DataRowView and get its Row property. The syntax is:

Kind of a pain, I know.

But wait. In your example, you already know the value ofwhat I'm assuming is the primary key of the row - the column named "AutoId". If your DataTable is strongly typed, and AutoId is in fact its primary key, then the typed DataTable has a method called FindByAutoId() that returns a DataRow. Just use that.

If it's not strongly-typed, then you don't have that method, but you can still find the row by its AutoId:

And if, for some reason, you actually need to know the index of this DataRow in the DataTable's Rows collection, you can get it via the DataRowsCollection.IndexOf method. Though I can't think of a good reason why you would.

I believe you're mistaken. This code doesn't produce any assertion failures:

In short, when I apply a filter to the binding source and use Find to find an item, the position that Find returns is the position in the filtered list, not the unfiltered list. There's something going on in your code that you're not expecting - perhaps the filter isn't active (or a different filter is) at the time you're calling Find.

That's the problem. It's returning the filtered row and not the unfiltered row.

I'll try and explain it:

Lets say we have a database with 4 weeks of data arranged by the day of the week; Monday, Tuesday, Wednesday, etc. x 4 weeks.

Lets say I filter it on Monday. Since there are only 4 Mondays in the 4 weeks, the filtered list will be 4 records long.

If I want the last Monday a filtered "Find" will return the 4th position, but it's really the 22nd (or whatever) record in the database.

From my 1st post:

Because it's filtered, this returns the wrong position:

tblChemicalsBindingSource.Position = tblChemicalsBindingSource.Find("AutoID", autoid);

Which in turn makes this datarow point to the wrong row:

DataRow dr = aocSQLDataSet.tblChemicals.Rows[tblChemicalsBindingSource.Position];


It's the DataRow that's now getting the wrong position.

Sorry, I'm new to this enviroment. Is there a way to get the correct DataRow using the filtered BindingSource?

Thanks,

Dennis

Oh, I see the problem. There's no reason to think that the nthitem in a BindingSource's List is also going to be the nth item in a DataTable's Rows collection. This is a feature, not a bug: it lets objects that consume bound data, like the DataGridView, process the items with a loop like this:

But there's no need to despair. There are plenty of ways to get the DataRow you want.

A BindingSource's List (if you've bound it to a DataTable) doesn't contain DataRow objects. It contains DataRowView objects. The DataRowView is a simplification of DataRow that hides some of DataRow's complexities (specifically, row versions) from the BindingSource. I don't think it's possible to build robust data-bound applications without knowing about the interactions between DataRow, DataRowView, BeginEdit, and CancelEdit, but for the moment let's pretend you don't care about that.

If you want to get the DataRow which is the nth item in a BindingSource's List, you have to cast the item (which BindingSource thinks is of type System.Object) as a DataRowView and get its Row property. The syntax is:

Kind of a pain, I know.

But wait. In your example, you already know the value ofwhat I'm assuming is the primary key of the row - the column named "AutoId". If your DataTable is strongly typed, and AutoId is in fact its primary key, then the typed DataTable has a method called FindByAutoId() that returns a DataRow. Just use that.

If it's not strongly-typed, then you don't have that method, but you can still find the row by its AutoId:

And if, for some reason, you actually need to know the index of this DataRow in the DataTable's Rows collection, you can get it via the DataRowsCollection.IndexOf method. Though I can't think of a good reason why you would.

The problem (if it's a problem) is that a strongly-typed DataTable is a class derived from System.DataTable. The DataTable.Select method returns an array of DataRow objects. It doesn't return an array of typed DataRow objects.

This means that when you're working with strongly-typed DataTable and DataRow classes, you still occasionally have to deal with type-casting issues. For instance, it would be nice to write code like this:

But that's a compile error, because the Select method returns an object of type DataRow[], not MyTypedTableDataRow[]. So you have to explicitly cast the result like this:

Fortunately, you can do implicit casting via enumeration. This will compile:

even if t is of type DataTable and not MyTypedTableDataTable. It'll throw an exception if any of the items in the array can't be cast as MyTypedTableDataRow, but you have to be pretty seriously bent on screwing yourself up to write code that would do that.

As are we all. It was not long ago that the above was a complete mystery to me. But as Yogi Berra said, you can observe a lot just by looking. Reading the various bits of code that VS generates is a really helpful exercise: not only do you often get the answer to your questions, you also get to see real production codewhich makes solid use of techniques that may still be unfamiliar. (Well, they were in my case.)

The code samples in the documentation are designed to show you how the framework classes work. They often do a poor job of showing you how to write robust code that uses them. The generated code has its idiosyncracies, but it's code that's designed for hundreds of thousands of developers to compile and run, often without even knowing it's there. It's worth looking at how code like that is written.