Think that you need to separate the steps, in the first step you may just steer the access: ADMIN or USER, USERID, Password (and Group). This would only regulate, who is allowed to open the document, and whether he is USER or ADMIN. In a second table you then may regulate access - either for each user on USERID or on the group for each other field in the application. Chapter 30.8 of the manual may guide you a bit further. Please remember that all entries should be done in capitals and resp. tickmarks in the document-properties should be set ("Initial Data Reduction ...")
I am not sure, whether I really get the point. You may add endless number of restrictions on other fields, the only restriction is that typically they are cumulative, i.e. if you restrict user A to see only Clients 1, 2, 3 and further restrict the user to see only company XYZ than he will only be able to see clients 1,2,3 if they simulteneously belong to compay XYZ.
Maybe you could add the company key into the KEY field ? In this way you would not have to split the section access fields ?
Or you create another table, let's call it GROUP_TABLE where there is 3 fields : KEY, COMPANY and RIGHTS_KEY which is concatenation of KEY and COMPANY. Then you add the Section access field RIGHTS_KEY ?
Even when you are able to filter data for a particular customer through the KEY field, the performance of the report in not good due to the fact that Detail and Client tables are large tables and joining by client field is taking so long. If the Client table would be previously filtered by COMPANY, this would reduce the size and therefore would increase performance (let me know if I didn't understand you right)
Unfortunately I haven't found a valid solution for this problem either, but any feedback will be welcome!!
I can see it's been a while since the original post, but this might help someone.
I have had a problem recently where I created an optimised table so everything loaded nice and quick, but in section access you cannot load an optimised table. The only way I have found to get around this is to UN-OPTIMISE the load by doing a where clause.