>uhm... how bout if i create index for the stockID and set it to candidate then put
>
>

SELECT(ThisForm.Tablename)
>
>IF !TABLEUPDATE(.T.)
>	MESSAGEB("UNABLE TO SAVE RECORD!",0+16,THISFORM.CAPTION)
>	RETURN
>ENDIF
>
>ThisForm.Refresh()
>
>

>
>will these also work?

It sort of would, except... The problem with this approach IMO is that stockID being a surrogate key, the program should never complain about its value -- it should just deal with it, since the end-user has no control over this key. They way to deal with it would be to keep incrementing the value until TABLEUPDATE doesn't complain any longer. However, how would you know for sure if it is the stockID rather than something else that stops tableupdate() from going through? It's just too much hassle.

In my experience, the best way to deal with this is to create a separate ID table, and when a user needs a new id, the program waits until it can lock the current table's ID row, gets the last ID, increments it, releases the lock and returns the incremented ID back to the user. You would, of course, need to build in contingengies for when the lock table is locked for a long time for some reason. And this is exactly why I always use a good framework to build my apps, because the framework has already dealt with the nitty gritty and debugged it, too.