As I said, I don't think the cursors are going to help the whole 10-12x issue.&nbsp; What I am doing is essentially very write-heavy.<br><br>I
read the table for some context.&nbsp; &quot;Dear database, what was the state of
the object last time I retrieved it from the network?&quot;&nbsp; The cursor
would help here, as right now I'm seeking each object one-at-a-time.&nbsp; A
cursor would eliminate needing to construct this query in the middle of
the loop, and store where I am in the B-tree (instead of skipping down
from the root every time).
<br><br>But, looking at the process browser, the messages in the
GLORP-operating thread seem to relate to the assembly of queries.&nbsp; The
cursor would eliminate the READ queries, but the WRITE queries are
still necessary, requiring assembly one-at-a-time, unless GLORP is
smart enough to use a global prepared statement underneath for
insertions.&nbsp; I see no reason why it shouldn't be -- insertions are very
homogenous operations, unlike WHERE clauses.&nbsp; Perhaps a cursor WOULD
solve the problem?
<br><br>Really, I need to profile the message sends to see exactly
where the CPU time is going, but one thing is for sure, the CPU is
pegged.<br><br>Jeremy<br>