ADO.Net Output Parameter updating child but not parent

EDN Admin

Well-known member
Joined
Aug 7, 2010
Messages
12,794
Location
In the Machine
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 Im actually using table2 as a datasource for a datagridviewcombobox in table1s datagridview.
So, my question is has anyone come across this before.
Ive already tried using both DataRow[] and DataTable objects for the OracleAdapter.Update() method, as well as tablemappings in the OracleAdapter object, but its 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: Ive 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 Im suspecting that perhaps my DataSet is just corrupt.

View the full article
 
Back
Top