Just to close it off for prosperity. I have a data table, filled by a table adapter with '...WHERE(PK=@PK)'. It had a single row in it. I added another row (.NewRow, .AddRow). The Rows count of the table was 2. Index [0] pointed to the old origional data. Index [1] pointed to the new data, DataRowState=Added. I then called the table adapter.update (a rather large INSERT statement) There was still a count of two rows but both [0] and [1] pointed to the same row, the origional. This would indicate the data table of the dataset is no longer valid after an Update. I then did another fill and the data table had both rows as before (now unchanged state). The reason for writing this is to record for other people that may fall into this minor but time consuming trap. The tableAdapter.Update call is the end of the road for the validity of the data table data. There isn't a lot of documentation or web resource that tells you this. It maybe obvious to seasoned .NET database engineers, and maybe standard practice. It would be unexpected to new entrants in this field with experience of other, dare I say it, more normal, caching systems. Thanks for the help. Ooops, I modified Table Adapter to refer more correctly to the data table of the dataset where referring to storage.
