At 11:09 PM 8/08/2004 +1000, you wrote:

>Another thought...
>if IBO is using DB_Key instead of the PK... in whatever circumstances..
>Now whe is the DB_Key invalidated?
>Doesn't it lose validity across transaction boundaries?

It can/should be expected to. It's "static" in the sense that it is
constructed on the basis of the row's physical location relative to other
rows on a page belonging to that table. It is likely to change if the row
gets updated, so it shouldn't be relied on outside the transaction context
that it's queried. A new recversion that's been written to a different
page and/or offset wouldn't be found by the db_key.

The exception, though, indicates that the *cursor* is lost. I got thinking
about what goes on with this "hands-off" transaction.refresh of
yours. Now, if a transaction is set up with Autocommit true, posting a
change or a delete on the current row commitretains the transaction - the
"soft commit" that holds existing cursors open. OK, now, say the user
starts editing something but doesn't post it. She goes off to lunch and,
while she's out, your timer kicks in and forces a
transaction.refresh. There won't be anything to commit, because nothing
has been posted since the last CommitRetaining. The hard commit ends the
transaction but it also, of course, kills the cursors.

The user comes back from lunch and brings up her screen where she left
off. Your transaction.refresh has reopened the dataset, but the unposted
edits she left in the control no longer match up with cursor handle,
because the hard commits have long since invalidated it. Hence, when she
tries to post, *that* particular edit is going to fail with the Cursor
unknown error; but any further edits will be OK, because they will take
place in the context of the *new* cursor.

If that's the case, it should be easy to catch that exception (its gdscode
is 335544572) and just swallow it.

Helen