Whats going on with the DAAB and UpdateDataSet?

[Karch]

OK, I've been staring and debugging for hours. Surely, someone else has run
into this problem. I have a typed dataset that contains 3 tables with
relationships between them. I need to insert the records for the first table
to get back the identity column for the subsequent inserts. However, after I
call UpdateDataSet the first time (and get back my identity and everything
cascades to the child tables just fine), the dataset returns false for
HasChanges() - meaning my subsequent inserts fail. How do I fix this
problem?

This is the code snippet that I have wrapped nicely in a try/catch block
with transactions. I have traced into the DAAB code and it looks like it
properly calls update using a dataadapter on the table only, and I cannot
see anywhere that AcceptChanges is called on the dataset. All help greatly
appreciated.

{

// this works just fine
rowsAffected = db.UpdateDataSet(
ds, TABLE_Company,
insertCommandCompany,
updateCommandCompany,
deleteCommandCompany, transaction);

// this thinks no changes and returns 0 rowsAffected
rowsAffected = db.UpdateDataSet(
ds, TABLE_EntityType,
insertCommandCompanyEntityType,
updateCommandCompanyEntityType,
deleteCommandCompanyEntityType, transaction)

// this thinks no changes and returns 0 rowsAffected
rowsAffected = db.UpdateDataSet(
ds, TABLE_Branch,
insertCommandBranch,
updateCommandBranch,
deleteCommandBranch, transaction);
}

 

[Cor Ligthert [MVP]]

Karch,

You tell and ask a lot, however to start you know that the update from a
dataadapter does a lot of things, by instance (this is probably not
complete)

open and close the connection as that not is done already
veryfying on concurrency if the SQL transact code is well done for that
update the database as everything is correct
do the acceptchanges on the handled table.

Maybe this gives some information why you have this problem

Cor

 

[Karch]

Yes, I realize that this happens in the dataadapter. I guess I am asking
about the remedy. This seems like a pretty serious shortcoming and/or design
flaw, considering the fact that the model only supports simple typed
datasets. What do I have to do, copy the complex dataset around, jump
through hoops, and merge stuff back together in order to have basic
transactional behavior? Or maybe I am just doing something wrong?

 

[Cor Ligthert [MVP]]

Karch,

We cannot look in your DAAB for you. Maybe you refer to Microsoft, but there
are plenty of others as well, while probably most visitors of this newsgroup
make their own Data Access Layers.

Cor

 

[Karch]

I completely understand what you are saying, Cor, and I appreciate your
time.

However, if MS is going to provide a solution as a reference architecture,
then it should support something this fundamental. I thought I would save
myself some time and gain some abstraction by using the DAAB, but now I feel
like it has backed me into a corner. I will have to endure the wrath of the
poor design of the dataadapter. I wish someone would explain the rationale
behind marking every row in every table in a typed dataset as current after
the execution of a command on a single table.

The only way around this that I can fathom is to create a copy of the
original dataset and work with the changes. Any of you written a workaround
for this? I have read everything on Google I could find and the message
seems to be...'tough luck, this is the way it works'. I will post my
solution later today...in the meantime, I hope someone offers something more
elegant.

 

[Karch]

Anyone from MS or Avanade have a suggestion, comment or recommendation about
this? Should I just GetChanges() and swap datasets in and out? I apologize
for harping on this, but does this not ad considerable overhead when the
UpdateDataSet could interact peacefully with DataRowState in the first
place? Why in the world does the update on a table make assumptions
regarding the state of the entire dataset?