One of the new features in ADO.NET 2.0 is the DataTableReader. I read about this and invented all kinds of great uses for it in my head. The DataTableReader is a firehose from a DataTable or DataSet, much like a SQLDataReader is from a SQL Database.

I dreamt of ability to disconnect the DataTableReader from it’s source and move it around. Thus having a really light weight version of the data much in the same way many of us will stream SQLDataReader (or other) into an array or some other object to move it around without any extra overhead. But I was so wrong – really misunderstanding this class because I hadn’t CODED anything with it, just read the documentation and hypothesized.

Actually DataTableReader is pretty cool. Not only do you have a new great way to iterate simply through a datatable or dataset, but it will really stream the data live.

Example – you create a SQLDataReader and halfway through reading through it, someone deletes a record in the database that is ahead of where you are in the stream. The SQLDataReader won’t reflect this change. If someone wants to delete a record that is before that point (I have only tested this by literally opening up the database), they can’t.

With the DataTableReader, if you have some asynchronous work being done, someone can possibly add or delete rows and the DataTableReader handles this really nicely. If you add or delete a row that is before the iterator’s row pointer, the row pointer will not be affected (I tested this) and if you add or delete a row after the row pointer, that change will be reflected as you continue to iterate through the rows. Suh-weet!

I also checked to see what would happen if you created a DataTableReader from a DataSet and then mid-stream, added a new DataTable to the DataSet. This does NOT get picked up by the DataTableReader.

Posted from BLInk!

  Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!