Preserving row pointer across an database update via a datatable
-
I am doing an update to my database after adding a row to the data table. The TableAdapter uses the VS2005 generated INSERT command (the table has a lot of columns). The line is... DishVarTA.Update(CurrentStDishVarRow); where 'CurrentStDishVarRow' points to the row in the 'Added' state. My problem is that I want to use the row data after this statement to format and send off to some machinery. After the Update however 'CurrentStDishVarRow' points to an entirely different row. I think the INSERT statement in the TableAdapter is putting the new row in at the beginning of the table so the row indexing changes. Is there any way I could preserve the pointer, or is the only way to fill the table again and/or find it again? Done a lot of searching and haven't found much that covers this, does that mean preserving row pointers across updates is not 'de rigeur'? Thanks,
-
I am doing an update to my database after adding a row to the data table. The TableAdapter uses the VS2005 generated INSERT command (the table has a lot of columns). The line is... DishVarTA.Update(CurrentStDishVarRow); where 'CurrentStDishVarRow' points to the row in the 'Added' state. My problem is that I want to use the row data after this statement to format and send off to some machinery. After the Update however 'CurrentStDishVarRow' points to an entirely different row. I think the INSERT statement in the TableAdapter is putting the new row in at the beginning of the table so the row indexing changes. Is there any way I could preserve the pointer, or is the only way to fill the table again and/or find it again? Done a lot of searching and haven't found much that covers this, does that mean preserving row pointers across updates is not 'de rigeur'? Thanks,
jrgrobinson wrote:
DishVarTA.Update(CurrentStDishVarRow);
This code will attempts to save changes in the indicated DataRow to the database. You can store the row before updating and then manipulate the new instance of required row. now to locate the row in the datatable before calling the update method for the dataadapter use one of this methods:
string s = "primaryKeyValue"; DataRow foundRow = datatable.Rows.Find(s);DataRow[] foundRows; foundRows = datatable.Select("put filter expression "); -
I am doing an update to my database after adding a row to the data table. The TableAdapter uses the VS2005 generated INSERT command (the table has a lot of columns). The line is... DishVarTA.Update(CurrentStDishVarRow); where 'CurrentStDishVarRow' points to the row in the 'Added' state. My problem is that I want to use the row data after this statement to format and send off to some machinery. After the Update however 'CurrentStDishVarRow' points to an entirely different row. I think the INSERT statement in the TableAdapter is putting the new row in at the beginning of the table so the row indexing changes. Is there any way I could preserve the pointer, or is the only way to fill the table again and/or find it again? Done a lot of searching and haven't found much that covers this, does that mean preserving row pointers across updates is not 'de rigeur'? Thanks,
You are using the built in wizard thingys to do your data processing and now you want to do something slightly different to the STANDARD methedology, like post processing after an insert. This is why they are a POS, I strongly suggest you read up on Data Access Layer and rework all your data processing. As that is probably going to frighten the day lights out of you (as it would most people) try and capture the row information prior to saving back to the database (take a copy/clone of
CurrentStDishVarRow) and see if you can work with that.Never underestimate the power of human stupidity RAH
-
You are using the built in wizard thingys to do your data processing and now you want to do something slightly different to the STANDARD methedology, like post processing after an insert. This is why they are a POS, I strongly suggest you read up on Data Access Layer and rework all your data processing. As that is probably going to frighten the day lights out of you (as it would most people) try and capture the row information prior to saving back to the database (take a copy/clone of
CurrentStDishVarRow) and see if you can work with that.Never underestimate the power of human stupidity RAH
I guess this is the problem with the 'standard methodology'. It is kinda hard comining into it to understand the conventions. There certainly isn't a lot except experience that would tell you an update rearranges the cache. A view from other worlds would be that a data cache wouldn't change after a write to the source, thus preserving some independance between the user and source. Been doing a lot of reading and SQLCommands are looking attractive, but copying across the database update will get my machines working tomorrow. Thanks for taking the time to respond.
-
jrgrobinson wrote:
DishVarTA.Update(CurrentStDishVarRow);
This code will attempts to save changes in the indicated DataRow to the database. You can store the row before updating and then manipulate the new instance of required row. now to locate the row in the datatable before calling the update method for the dataadapter use one of this methods:
string s = "primaryKeyValue"; DataRow foundRow = datatable.Rows.Find(s);DataRow[] foundRows; foundRows = datatable.Select("put filter expression ");Thanks. Just a simple question, after the update, could I assume the rows are all still in the TableAdapter and do the Find or Select then? Thanks
-
Thanks. Just a simple question, after the update, could I assume the rows are all still in the TableAdapter and do the Find or Select then? Thanks
TableAdapter don't store any rows, it just provide communication between your application and a database. try to read this article to get more info:http://msdn.microsoft.com/en-us/library/bz9tthwx(VS.80).aspx[^] The Datatable represents one table of data, so you should depend on the datatable to use the find or select methods.
Like what you do if you can't do what you like :)
-
I am doing an update to my database after adding a row to the data table. The TableAdapter uses the VS2005 generated INSERT command (the table has a lot of columns). The line is... DishVarTA.Update(CurrentStDishVarRow); where 'CurrentStDishVarRow' points to the row in the 'Added' state. My problem is that I want to use the row data after this statement to format and send off to some machinery. After the Update however 'CurrentStDishVarRow' points to an entirely different row. I think the INSERT statement in the TableAdapter is putting the new row in at the beginning of the table so the row indexing changes. Is there any way I could preserve the pointer, or is the only way to fill the table again and/or find it again? Done a lot of searching and haven't found much that covers this, does that mean preserving row pointers across updates is not 'de rigeur'? Thanks,
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.