At 07:36 AM 30/01/2004 +0100, you wrote:

>Helo Hellen,
>
>thanks a lot for you detailed explenation. I will review my app in order
>to follow your hints and advises.
>
>
>
> >I have a KeySource-Lookoup relation on the process data using a
> >IB_LookupCombo dropped on the grid.
> >If the user now selects the field to modify the lookup combo comes up
> >giving him choice from a other table. If now the corresponding dataset
>
>row?
>[Queck Rainer]
>yes, sorry for confusing
>
> > gets copied to the archive before the user made his choice
>
>How does this happen? An embedded lookup only works during edit mode. I
>fail to understand how the app could post anything while the lookup
>operation was incomplete.
>[Queck Rainer]
>It is not my "Visualisation" I am talking about that causes the data to be
>moved to to the archiev it is the "MainProcess" running in the background
>doing this. Actually it is a trigger on the table, working after update
>that moves a row from one table to an other if the data in the row is no
>longer needed.
>I also thought that it should not be possible for a other app to "move" a
>row to a other table while a lookoup is in process. May be it is not that
>the row is no longer there but a keylink related problem also?

A keylink problem *certainly* (RDB$DB_key tells us that). Your transaction
keeps its view of the database state. Now, depending on the transaction
isolation of *your* transaction, it can see work committed by other
transactions (tiReadCommitted) or it retains its snapshot view
(tiConcurrency). Now, if you get your Keylinks right, then you will not
get this "Record was not located to delete" error at all. If you are using
tiConcurrency, you don't get *that* error when the record has been deleted
by another transaction: you get a locking conflict of one sort or another.

If you are using tiReadCommitted then, yes, it could happen that you get
"Record was not located.." for either an Update or a Delete. In that case,
you seem to be making this problem for yourself by not keeping the dataset
refreshed. With a ReadCommitted transaction you can refresh any time: and
a good time to do it is when you have just successfully committed
something. That way, you can keep "what the user sees" more closely in
sync with "where the database is at". Play with the CommitAction property
of the query: caRefreshKeys is great, provided you have those KeyLinks
right. caRefresh is OK, too, but, again. your Refreshes will be ugly
without those keylinks.

Keylinks Keylinks Keylinks Keylinks Keylinks Keylinks Keylinks Keylinks
Keylinks Keylinks Keylinks Keylinks Keylinks Keylinks !!!!!!!!

Helen