>>Naomi,
>>
>>everything you read in this thread is true.
>>Update is slower than replace through different locking strategies.
>>The fastest way to iterate would probably be small seek-scan while loops -
>>these can be waaay faster if rushmore has to load the indices again often.
>>This might be happening here - perhaps you "invalidate" the current rushmore
>>map often by "dirtying" the cdx.
>>
>>Also - if possible work on exclusively opened tables.
>>
>>If possible work all the changes in each table in one block:
>>my gut reaction would be to try for this way of coding,
>>even if it might mean "more code".
>>
>>But as always: measure <g>. Build an array for each update/insert
>>cumulated time as well as the variance - this should tell you enough.
>>
>>HTH
>>
>>thomas
>
>Hi Thomas,
>
>Nice talking to you as always. I'll switch to seek and replace while and hopefully the performance improves. I'm using the tables in shared mode and with buffering 5. The CommitChanges method is going to do begin transaction and tableupdates on all these tables.

Naomi,
Did you run a coverage profiler to make sure you know exactly where the slow up is? I have been suprised many times by the results.
Sammie