>>>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.
>>
>>Hi Dragan,
>>
>>I want to test value immediatelly after focus is trying to leave the textbox. Additional check would be performed at the stage of saving. So, here is the simple potential scenario:
>>
>>One userA opens table in buffered mode. He switches to Editmode and go to record 4. He changes FunName to "MyFun1". Then he goes to lunch. After lunch he goes to record 8 and changes funName to "MyFun1" or tries to add a new record with 'myFun1'. Since the changes are not saved on disk yet, your method would allow him to do it. I want to catch this invalid input immediatelly.
>
>Alternately, you can say this one is OK, because there's no such thing on disk, and yell at him when he tries to save record 4. It just depends on what you take for a rule.
>
>>So, only COUNT FOR should work (or seek and do while (or scan while)). Since these operations move record pointer, I would have an error, which I should trap.
>
>That's why I said 'using the file again', because if you do
>

if not used(thisfile_2)
>  select 0
>  use thisfile again order fun alias thisfile_2
>endif
>select thisfile_2
>count for fun=cMyFun

>it will not move the pointer in ThisFile. The whole thing with the Use...Again is to have two sets of buffers, two record pointers and two aliases based on the same table.
>
>As a sidenote on what you can do with a Use(d)...Again table: you can even set a relation between them, if you ever need that. You can set a relation from two different fields in another workarea into this, like in case of any two-sided interaction (court case, sale, phone call etc) where you have the initiator's in one field, the subject in the other, and a common lookup for them both. Simply open the lookup twice and that's it.
>
>> That's why it's quite complicated task and I want to discuss it with colleagues first. Though, I know in advance the answer: yes, we understand the problem, but it's a low priority problem, etc., etc. So this would never be implemented anyway and I have to deal with it on the particular form level...
>
>This trick with using the table twice (Mark has mentioned it already - but it got sidetracked somehow) will make this simple enough and will allow you to check on a single guy creating duplicates (or at least attempting). Still, you won't know if there's another guy somewhere trying to create a potential duplicate - see my previous post - so you'll have only a partial solution. Short of writing all proposed key changes into an unbuffered table and checking them there (which further complicates the matters), I think full control on this is not feasible.

Dragan,

It doesn't matter, are you opening a table again or perform SQL, in both cases you're checking against file, which is saved on disk. If you have table-buffered table (5) and you go to record 1, change value to value1, when go to record2, change value to value1, etc., etc., you can change your whole table to value1 and it would be caught only when you try to save records. Anyway, since it's potentially rare situation, when one user would change records in the same table with the same value, I used our main class, which uses SQL approach. BTW, I found a problem in our class too (it's not generic enough, so if I use upper(FunName) as key expression, it doesn't compare with upper(textbox.value), it still compares with textbox.value, so I had to write a special valid anyway).

COUNT FOR in the same table + trapping of error seems like a better approach for buffered table, but I didn't try to implement it.