Thanks, Mark!
Well, yeah, got a lot of metadata already and generalized search,...
I just wanted to be lazy with the BROWSE, hoped to catch the cryptic error message and supplant it with a real German one.

And my first impression was, that VFP allowed duplicate keys in the BROWSE. About further inspection it seems it DOES NOT really SAVE, but REVERT, so I´m ok with that behavior for now.

I fear grid performance with, say, 500K records, which is ok with a simple BROWSE. Guess I´ll play a little bit...
Thanks
G

>
Why not allow them to edit this data in a grid where you can better control what they have access to? You could also create a new table of meta data that can be used to determine which fields in each table are editiable. Then use that information to determine which fields/columns in this grid are read only.
<
>>
>I used to allow customers, when they logged single user, to change data in a simplistic BROWSE, where they could do some emergency changes.
>I used to have just REGULAR indexes.
>In forms I catch uniqueness violations with a VALID.
>
>When I change an index to CANDIDATE now I don´t seem to be able to catch the global BROWSE error when uniqueness is violated by a key field being changed.
>
>Do I need to generate a BROWSE FIELDS with a VALID clause for the unique field for every table in question now?
>Thanks
>G<<