DataRowState

Posts   
 
    
jeffreygg
User
Posts: 805
Joined: 26-Oct-2003
# Posted on: 29-Oct-2008 22:30:39   

Hey, Frans. Did the DataRowState of the rows in the DataTable that's generated via FetchTypedList change somewhere between v1 and v2? I'm upgrading a large codebase from .NET 1.1 to .NET 3.5/LLBLGen 2.6 and seeing some differences in behavior.

In particular, I think that the datatable's rows used to be set to DataRowState.Unchanged when the data was fetched and now they're set to DataRowState.Added, but I'm not sure. It's something I can resolve by calling DataTable.AcceptChanges(), but that's alot of calls to make, and I'm just trying to figure out where the difference took place. Thanks.

Update I override FetchTypedList to call .AcceptChanges(). Any idea whether that will cause problems?

Jeff...

Walaa avatar
Walaa
Support Team
Posts: 14946
Joined: 21-Aug-2005
# Posted on: 30-Oct-2008 09:58:33   

Update I override FetchTypedList to call .AcceptChanges(). Any idea whether that will cause problems?

I don't think so.

But also I don't think a change was made in this part from our side.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 30-Oct-2008 12:41:19   

The typedlists/views/dyn. lists are now filled through our own datatable filler routine which utilizes string caching, so memory footprints are much lower.

This routine adds datarows using NewRow() and Rows.Add(), and doesn't set a state for the row. I see that setting the state after the row was added isn't really possible other than calling AcceptChanges() on the row.

Using reflector I see MS does that too internally in the DbDataAdapter, it calls AcceptChanges on all rows added. They also do BeginDataLoad(), something I don't do so I'll add a call to that too.

I'll attach a new build when I'm done for you to test.

(edit) attached. (so you don't have to call AcceptChanges anymore with this build. )

Frans Bouma | Lead developer LLBLGen Pro
jeffreygg
User
Posts: 805
Joined: 26-Oct-2003
# Posted on: 30-Oct-2008 18:19:32   

I appreciate that, Frans; thanks. One note though, is that this might be a breaking change for some people that won't occur until runtime. It would restore the functionality back to what it did in v1, but that behavior change between v1 and v2 broke my code, so presumably changing it back might break someone elses.

Where this affected me was when databinding to a grid. Rows that are in the "Added" state are marked as "Detached" when they are deleted. Rows that are in the "Unchanged" state are marked as "Deleted" when they are deleted. The difference is that when the row is in the "Detached" state, the row is physically detached from the underlying datatable and none of the fields are readable which is where I caught the problem.

There may be some people out there that are testing specifically for the "Detached" state or are otherwise making decisions based on that assumption. Just a heads up.

Jeff...

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 30-Oct-2008 19:05:21   

Hmm... well, the case where this happens is on datatables which are considered readonly ( typedview/list), so my guess is that IF people run into this, it's really an edge case, and I think what you brought up is a bug so the proper fix is to make this change. As it worked before like you described, it's to me best to bring back the normal behavior back, thus with the Unchanged setting.

Frans Bouma | Lead developer LLBLGen Pro