Geert,

Maybe you can get better results using an updateable view?

I'm not exactly sure why it gives the error, but I can see how it could be confused at to what entry should exist in the index. BTW, it is not just a SEEK which can generate this error...anything that moves the record pointer causes the error.

Let's assume it does not give an error:
Which record do you think the SEEK should return? The one that was deleted, without issueing a tableupdate()? Or the the one you just added, without issueing a tableupdate()?

Another thing, is the code does not work even *without* the SEEK...the tableupdate() fails before that point.

set multilocks on

if not used("buyers")
	use buyers in 0
endif
select buyers
cursorsetprop("buffering",5)
locate for buyerid = 144
delete
* not issuing a tableupdate() at this point causes a problem.
append blank
replace buyerID with 144, ;
	lastname with "tst"

? tableupdate(.t., .t.)   && the tableupdate returns FALSE
skip -1  && we crash here, but the update has alread failed 
         &&    before this point in time

But, as you are not doing, it works if you add a tableupdate() after the DELETE, and wrap the entire thing in a transaction. But I would think having a transaction in progress while a user is entering data on a form is not the best course of action.


>Thanks for your advice Steve, but I use begin and end transaction to do the job. But I am still curious why the code is giving the error.