>Hi Doru,
>
>>If we go back to the scenario described in the original post, we do not add/insert records to that table. From what you and Jim say, I stil don't know if TABLEVALIDATE 2 will be any different than TABLEVALIDATE 0 for that scenario.
>>
>
>If you don't modify the table, TABLEVALIDATE=2 doesn't do anything for you.
>
>>What I wanted is this: validate the header when you USE the table , BUT, do not trigger an error if the header cannot be locked, IOW do not assume anything if the validation cannot be performed. Wasn't this how things were in FPD/FPW?
>>
>
>Validation is either performed or not performed. If you use TABLEVALIDATE=1 or 3 then you ask for the validation that locks the header and thus failure to lock the header can not be ignored. If you don't care about this validation, use TABLEVALIDATE=0 or 2.
>
>There is an easy workaround, try it first with TABLEVALIDATE=1 the if it fails due to the lock conflict try it with TABLEVALIDATE=0.

I have the feeling nobody realy understood my post, the answers seem to... work around my question.
My translation into a straight answer is this:
- TABLEVALIDATE cannot do the header validation as it was done in FPD/FPW.
- There is a flaw in the design of this new feature: it triggers an error when the validation was not performed.

The consequence is that in terms of header validation I can get less now than in FPD/FPW. Due to applications requirement I am limited to have TABLEVALIDATE=2, and that will only validate on appends, not on USE.
I hope somebody proves I am wrong.

>
>Thanks,
>Aleksey Tsingauz.