It seems your situation is quite different from mine. I restricted access to entire forms (and therefore, to the corresponding tables), based on access level. You want to filter records, also based on the access level.

I think that a filter is appropriate. An index on the security level might help.

How about representing the entire tree structure in a field, concatenating the fields to build up the hierarchy; in your example:

Information of level A:

A

Information of level C:

ABC

Information of level F:

AEF

Thus, if you filter on SecurityField = "AE" (with SET EXACT OFF), or left(SecurityField,2) = "AE" (independent of the SET EXACT setting), you will get information for fields with level "AE" (that is, "E" in your tree diagram), and "AEF" (that is, "F"), but not for "A".

An index on SecurityField will probably help make the filter (or SELECT - SQL, or view) faster.

HTH,

Hilmar.

>It is this grouping into departments or workgroups that i am having trouble with or am unsure which way to go.
>maybe i didn't explain it properly. the issue is thus:
>i have a tree structure representing the security as below
>A--B--C--D
> `-E--F
>
>if a person logs on with security access A, no filtering is needed on the main table as they can access all information entered by all users.
>however, if security level B logs in they can only access level B, level C and level D data. similarly if level F logs on they can only see level F data (the level of the data is represented by what level the person was when they entered the information).
>
>what i have done is added a field on the main table to record the security level of the person logging the data. my question is, will it be too slow if i use the SET FILTER command to filter the main table if the number of children to the security level could be in the hundreds? or is there another way to record the security to the table?
>
>Jordan
>
>
>>With the help of the Visual Extend framework, I do the checking of user-levels with a list of forms.
>>
>>A table of forms includes the form name, and levels required for open, edit, delete, ...
>>
>>The user table, of course, lists the user-level as well.
>>
>>Instead of placing each form somewhere on the menu, there is a special form that lists available forms. This list is populated through a SQL - SELECT command, which of course can specify the user-level.
>>
>>Having a form open your forms, instead of placing each form on the main menu, is very flexible; it becomes easy to add or delete forms. Just add an entry into the forms table!
>>
>>Note: The above functionality was built-in, into the Visual Extend framework. I extended it for my own purposes, mainly in that I added a "department" field (some forms are only relevant for certain departments (or sections, or workgroups), within the company).
>>
>>>Hi all,
>>>i am working on bumping up the security on the system i am developing and i have hit a bit of a cross-roads. what i need to do is as follows:
>>>--create security levels like a tree structure. top level can access all information. second level can only access info at it's security level and all levels below it. and so on.
>>>--have the ability to have variable number of security levels. ie. not tie it down to say 6 levels of security.
>>>--filter the main system table based on the security level of who logged in.
>>>
>>>the issue occurs here. how do i approach this. do i add a new field to the main table to hold what the security level was of the person who logged the info? and then, when someone logs on i have a list of security levels it can access and filter on the records that have these security levels? (sounds like it might be slow).
>>>or do i, at the time the user saves, concatenate a string together consisting of all the security levels able to access this record and filter on the table whether the logged in security level is contained within that string. (seems to stagnant. what if a new sublevel is added to the security that should be included).
>>>or is there another way someone can think of? perhaps linking in the security table somehow (the security table at this stage resembles the info needed for creating a treeview - id,parentid,levelname,type,image).
>>>any help with record level multi-access security would be much appreciated.
>>>
>>>thanks,
>>>Jordan.