ADO.Net Output Parameter updating child but not parent

Question

All,

The title pretty much says it all.  I have a typed dataset, but am manually managing the read/write to my database using adapters (odp.net, but since it inherits from SqlDataAdapter, I thinkt his is more of a .Net issue then an ODP.Net issue [though I could be mistaking]).  I have within my typed dataset a datatable (table1) with a nested relation to another datatable (table2).  Table2 also forces a foriegn key constraint (foreign key constrain only) on table1 with cascading updates.

For some reason, when I attempt to update my data, the output parameter returns, but is written to the child table (defined by FK constraint) INSTEAD of the parent (though all the input parameters seem to write ok to the database from the correct data-table).  What is even more bizzare is that I have this exact same setup with other data-tables in my DataSet and those seem to be working ok.

For my setup, this becomes an issue, as I'm actually using table2 as a datasource for a datagridviewcombobox in table1's datagridview.

So, my question is has anyone come across this before.

I've already tried using both DataRow[] and DataTable objects for the OracleAdapter.Update() method, as well as tablemappings in the OracleAdapter object, but it's as if the output parameter binding is ignoring table2 and going directly to table1 for some reason.

I should note that the two related columns in the datatables have the same name, but this SHOULD be of little consequence since I am 1) explicity providing a datamapping to the OracleAdapter object, and 2) explicitly passing either DataRow[] or DataTable objects to the OracleAdapter.Update() method.

Thanks in advance.

EDIT: I should note that when I delete the foreign key, the data returns correctly to the correct datatable, but when I add the foreign key constraint back, it seems output parameter seems to jump over table2 and go straight to table1.

EDIT: I've also tried changing the name of the column in Table1 and altering the SQL to map to the altered name.  This has had no effect, however it eliminates a possible collumn confusion with ODP.Net, since the SourceColumn calls out a unique column in my dataset.  This can only mean that there is a bug with ADO.Net (at least with this particular DataSet).

My next step will be to recreate the DataSet and see if this helps, as I'm suspecting that perhaps my DataSet is just corrupt.

Answer 1

All,

I figured it out.  Turns out it had to do with concurrency issues.  Since I had two binding sources, I needed to suspend binding before saving (but after calling the appropriate EndEdit; one of the binding sources was for display only).  Once I did this, Everything flowed as it was supposed to.

Cheers.

Edit: What's weird, though, is that I had the exact same setup with another pair of datatables in the same dataset.  Not sure what was different (besides the number of columns), but I didn't run into this issue with the other one.

Answer 2

Hi whiteheadw,
I’m glad to hear that you have solved the issue and thank you for sharing it with us.
To the new question, I suggest you create a new thread in the ADO.NET forum.
Best Regards,

---

Bob Wu [MSFT]
MSDN Community Support | Feedback to us