>>>Thanks again. So basically COUNT FOR +Trapping uniqueness of index is violated error should work. I have to think about it and discuss with my colleagues. I can make changes for the particular form, but it's better to make the changes on the class level.
>>
>>I prefer the SELECT COUNT(*) on the buffered view/table because the count is retrieved into a cursor and leaves the source table as is with the record pointer on the same edited record.
>
>Mark,
>
>AFAIK, SQL works with table directly, in other words, it would not see the buffered changes. What's why this method in not 100% correct.

But then what are you checking against? How many users are having buffered changes at the same time? Even if there's more than one, you can still run the validation against the disk file - anything in buffers is not accounted for until the moment of saving. So yes, you can have a situation where one user wants to save FNA while there's FNA on disk already, while another user is actually renaming FNA to FNB but it's not saved yet etc - but there's no way you can read someone else's buffers. This means that from the standpoint of one instance of your app, there's no way you can be aware of what the other users are doing, until they (try to) save. So the only thing you can compare against is your own buffers and the disk file.

The method with using the file again and doing a seek() or indexseek() on it will check against the disk file and probably your local changes (still not sure and may need testing). SQL select will read only the disk file. There's no way that I know of that you can do this, unless you turn buffering off.