Hi Vlad,
Another alias or SQL you get the results from committed ones, right. What I meant was another user might also be checking for duplicates with same logic and 2 or more users might have values that 'they think' as not a duplicate (all use buffers and check from disk copy). Only time they could notice this is during update IMHO.
When saying index updates for buffered I meant buffered index not table. Hard to express with words :)

use sometable
use sometable in 0 again alias 'SameTable'
cursorsetprop('Buffering',5,'SomeTable')
insert into sometable ('myfield') values ('aa') && Assuming not exists
insert into sometable ('myfield') values ('bb')

? seek('aa','SomeTable','myField'), seek('aa','SameTable','myField')

Cetin

>Hi!
>
>What about select count(*) from MyTable where MyField = MyNewValue
>
>count(*) should return zero if no duplicates, because SELECT statement works only on the phisical data taking no data from buffers. THis also does not require to open another alias for duplicates checking. However, after this post I'm not sure. If index is updated from buffer (that wonders me a lot because I beleived before that indexes are updated only after buffer is updated), then Rushmoure optimization can cause also SELECTs tatement work incorrectly. Just try it...
>
>HTH.
>
>>>IndexSeek() appears to me to be showing unexpected behaviour when used on tables that are being table buffered.
>>>
>>>If I make changes to an indexed field and then use IndexSeek() I can get it to return true for both the old field value and the new field value. I would have expected it to return true for the old value but to return false for the new value which is still sitting in the buffer.
>>>
>>>What I'm trying to do here is simply replace the old way we do our form validation when saving. We currently have the table opened twice and use the second alias to do lookups to see if duplicates have been entered. I thought it would be nice to use IndexSeek instead but have found that this function is reliable provided we are using record buffered but as soon as we use table buffered we get anomalous behaviour.
>>>
>>>This is easy to reproduce in a browse window with any indexed table. Make sure it is table buffered and then edit the content of an indexed field. You can then see two different behaviours depending on whether or not you step off the record being edited.
>>>Assume you stay on the record you changed all is well, IndexSeek for the original field value returns true, IndexSeek for the newly entered value returns false.
>>>Now step off the edited record to a different one, IndexSeek for the original field value and the newly entered value both now returns true, presumably an index key got created when you moved to a different record even though the original index key still exists as well, I would have expected nothing to have happened to the index until TableUpdate() was issued.
>>>
>>>What is even more undesirable is the behaviour that you get if you make the lMovePointer parameter true. IndexSeek for the new value moves you to the edited record in the table but IndexSeek for the old value moves to the next record after the edited record, presumably because it's trying to go to the record with the old value but it isn't there anymore.
>>>
>>>David
>>
>>Unfortunately this is known behaviour of IndexSeek. It sounds it isn't meant to be what it was meant to be. Index is updated for the buffered table but applies to buffer only. IOW after you enter a value you could seek() it in buffered table but not in unbuffered copy. Once you move the pointer indexseek() and seek() seems to be identical (except pointer moving parameter). What you were doing IMHO slightly more reliable. However it doesn't too prevent duplicates caused by another buffered table user. The only reliable way I can think of is candidate indexes with an error handling scheme.
>>Cetin