Very Computer

What you need to do is to look at your algorithm.  For example, keep the
tables open.  Do a batch of updates at a time, protected by one table-lock,
instead of relying on record-locking each time.  

In a file-server system especially, *communication* is often the bottleneck.  
In your scenario a lot of data is passing over the wire each time.  There are
a lot of directory-searches, file operations etc. being performed.

So, it -is- your coding technique.  I suspect that if you put your mind to it
you can get those eight minutes back.

Also, is there a way to issue an UPDATE query instead?  Cache the updates the
user makes, then start a transaction, fire off a slew of UPDATE queries, then
commit.  (Depends, of course, on exactly what DBMS you are using!)  :-)

An analogous operation would be to cache the updates locally, then grab a
"Write" lock on the table, boom through all the update operations in a batch,
and then release the "Write" lock.  This carries a whole lot more "payload"
with a single batch of read/write operations and gives the DBMS plenty of
opportunities to avoid redundant operations.  For example, acquiring a "Write"
lock means that individual record-locks are no longer required.

Quote:>The FindKey - Edit may be replaced with Append.  This seems very
>straightforward and simple, such that it shouldn't be slow because I
>would think it is a very common algorithm for adding and editing
>records.  Does this algorithm seem inherently slow to anyone?  I'll
>leave the tables open and try it but what about corrupted indexes if the
>machine hangs up or is turned off?