How to update a few thousand records

Published 14 May 04 09:54 AM | despos

I believe that in data-intensive applications (uh, are there really other types of apps?) there are a few problems to avoid, rather than brilliantly solve. One of this is SQL paging. Another one is, maybe, large batch updates. Of the two, the latter looks much more approachable. None of the two, however, find a system level solution in .NET 1.x.

(A system-level solution here means something the framework provides that gives you a good excuse to take it for granted and avoid thinking of a better approach.)

No matter SQL paging is supported in the PDC build of Whidbey (and even in the March04 Community Drop), it won't be in the final product. Rumors say that there will be an add-on or, maybe, a service pack shortly after with some enhancements including SQL paging, server cursors, and more.

What about batch update improvements?

In version 1.x, batch update submits one record at a time. All the overloads of the data adapter's Update method end up calling the one that processes an array of DataRow objects. The implementation simply loops through the array, decides which command to execute, and goes with that. You understand that 5,000 records to batch update are definitely a pain-in-the-neck. At a minimum.

What's a good way out, if any?

My knee-jerk answer is saying "avoid that rearchitecting the app." In alternative, grouping multiple rows in a single batch update step would alleviate the issue. In 1.x, the batch update size is hard-coded to 1. In version 2.0, there's a new property BatchUpdateSize you can use to fine-tune the whole process.

I hoped some hack was possible in 1.x to force a custom batch update size. My hope was for a private, internal property to set using reflection. No way. And in 2.0, the batch update implementation is significantly different and concatenates more statements into a SQL batch.

Have you tried with SQLXML updategrams? Any real-world feedback from large scale projects? 

Comments

# TrackBack said on May 13, 2004 11:55 PM:
# TrackBack said on May 14, 2004 02:57 AM:
# TrackBack said on May 14, 2004 06:23 AM:
# Peter said on May 14, 2004 08:18 AM:

>>No matter SQL paging is supported in the PDC build of Whidbey (and even in the March04 Community Drop), it won't be in the final product. Rumors say that there will be an add-on or, maybe, a service pack shortly after with some enhancements including SQL paging, server cursors, and more.<<

Geeez! Please, say that this was a joke. Pretty, please...

# Kyle Tinsley said on May 14, 2004 09:18 AM:

Did I read this right? Data-paging will NOT be a part of the final ADO.NET 2.0? First ObjectSpaces and now this...what's the data team thinking?

# Brian R. James said on May 14, 2004 10:24 AM:

I must be missing something. Data-paging is the domain of the stored procedure. Why would I want to transfer thousands of records over the wire to the app server so that ADO.NET can carve up 20 and display them?

# chris hollander said on June 9, 2004 06:01 PM:

actually, a colleage of mine and I used to discuss the "huge batch update" problem, and we came up with a good theoretical solution; he was going to put together a proof of concept, but I don't think he ever got around to it. the solution was based on the existing 1.0 dataset/dataadapter architecture. the key was to provide custom implementations of an IDbCommand class for the data adapters update,insert, and delete command properties. whe you called the update method on the data adapter, it would rip through the dataset, determine which command to execute for each changed row, and call into ("visit") our custom BatchedIDbCommand instances. each of the BatchedIDbCommand classes would construct a single compound statement containing all of the changes that the dataadapter found in the dataset. after the call to update, you would call Commit() methods on the BatchedIDbCommand instances.

The problem, of course, is handling exceptions. it would take careful crafting to allow the batched sql command to continue upon failures, and report those failures accurately.

Leave a Comment

(required) 
(required) 
(optional)
(required)