DataAdapter

[Kntx]

So I have this DataSet. It has a recursive relation defining a tree structure. I have this nice UI that prevents you from deleting non-empty folders. What you can do, is delete leaves then delete branches from the bottom up.

When the user is happy, they can hit a little save button. This grabs the changes from the DataSet and sends them to a webservice. The webservice then uses dataadapters to commit the changes to the database.

I was thinking that since the deletes occur from bottom to top on the tree, the dataadapter would know enough to delete them in the same order. Wrong!! It does reverse order, like the deletes are on a stack or something.

Someone tell me there's a good reason for this. Usually when something in .NET is upseting me, a good reason for the behavior is revealed down the line. What's the good reason?!?!?

 

[UCJefe]

The "good reason" is that the order of deletions should not matter in most cases and actually in certain cases (see below) you HAVE to go top-down (which coincidentally .NET doesn't enforce either). When the DA goes through and updates every row, it is not done in a top-down, bottom-up, or stack matter. The order isn't saved at all. It just simply gets a list of rows that have been deleted and it is (most likely) ordered by your primary key column.

I have actually been bit by this exact same scenario. Had a "Folders" table with an ID and Parent_ID columns to for a recursive hierarchy. Deletions weren't actually a problem for me since I didn't have the foreign key relationship specified in the DB (only in the DataSet) so I didn't care what order things were deleted in, but insertions and updates were a problem since I was using optimistic concurrency and auto-increment ID's. The parent folders HAD to be updated before the children so that the new auto-increment ID could flow down to the children before they were inserted. So I forcedit to be top-down. If you require your deletions done bottom-up, you'll likely have to do the same.

I'm sure they probably could have been a lot smarter here when dealing with recursive tables but since it's pretty easy to workaround, they likely didn't bother. It's definitely a bit of a pain though (especially after debugging for hours).

Edit What the heck is up with the "Attach Code"?? It looked fine when I hit submit and turned into that monstrosity. Anyway, if you want to see that, you might have to paste it into VS.NET and hit the last curly brace to reformat. grrrrr

 

[Kntx]

Hmm.. Thanks for the reply.

I think I'll just drop the constraint in my delete SP, then add it back after. It pains me to do this as it's a bit sketch. Oh well.

Maybe one day I'll write a compromise free program. But not today!

 

[Kntx]

Scratch that, found a better way.

// process deletions in reverse order (bottom of tree up)
DataRow[] DeletedRows = D.Row.Select(null, "RowID DESC", DataViewRowState.Deleted);
if(DeletedRows.Length > 0) {
RowAdapter.Update(DeletedRows);
}

edit: yea, attach code is balls.