When a form is opened from a command button or menu item, C/SIDE automatically applies record-level security filters to the main record variable used in the form, provided that the command button or menu item in question uses properties to run the form, and not code.

Similarly, when a report or dataport is opened from a command button or menu item, C/SIDE automatically applies record-level security filters to all the record variables used in the request filter tabs, provided that the command button or menu item in question uses properties to run the report or dataport, and not code.

C/SIDE does not apply record-level security filters to user-defined global and local variables. To help users stay within the defined security filters, you must include the appropriate statements in the code that applies the filters. Security filters are applied on a record variable by using the SETPERMISSIONFILTER function that is available for the record variable.

Example

The following code example finds the first record within your read-permission security filter.

	Copy Code
Customer.SETPERMISSIONFILTER; Customer.FIND('-');

Record-level security filters affect performance in the same way as other filters that are applied by the user. It is important that the record-level security filters have matching keys in tables that contain many records, and that these keys are used. C/SIDE does not automatically select the most effective key to use. If, for example, a security filter specifies that a user is only allowed to see records that he created by placing a filter on a field called User ID, the matching key must start with User ID. Furthermore, to ensure the best performance, the user must select the User ID key when opening the form for the first time. In some situations you can choose to change the default sorting in the form, or in the command buttons, menu items, and code that opens the form.

Concepts