Enabling Row-Level Permissions
This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.
To implement row-level permissions for any specified main table in a team solution, you must first enable this feature for that table. Then, you must create a user-interface, so users can use row-level security.
For information about team solution security, see Security Permissions Model and Defining Table Security.
To enable row-level permissions for your solution
In the Access Workflow Designer, open your solution. For details, see Accessing Access Workflow Designer Tools.
Use the Main Table Selection wizard to select your main tables. For details, see Identifying Main User Tables.
In the Object List, select a main table.
On the General tab of the Tables pane, select or clear the Enable row permissions box to enable or disable row-level permissions.
For information about building a user interface that takes advantage of row-level permissions, see Creating a Row-Level Permissions User Interface.
Considerations when Using Row-Level Permissions
When row-level permissions are enabled for a user table, they are enforced in the view that is created for that table. Therefore, users should access the table only through this view.
In order to enforce access through the view, Access Workflow Designer modifies the permissions on the base table. The changes prevent users from retrieving data directly from the table. At the same time the changes enable data access pages to send updates, inserts and deletes to the table.
The Access Workflow Designer only modifies the base table permissions if the table has a primary key when row-level permissions are enabled. The primary key is required by data access pages in order to update the table.
Modifications Made to Base Table Permissions
When you enable row-level permissions for a main user table, the following changes are made to the base table and to its associated detail tables.
Revoke SELECT permissions on the table.
Grant SELECT permissions to PUBLIC on all the columns of the primary key. This is required to enable updating and deleting rows from data access pages.
Grant INSERT permissions to PUBLIC on the table. This is required to enable inserting rows from data access pages.
Grant UPDATE permissions to PUBLIC on the table. This is required to enable updating rows from data access pages. Row-level security is enforced by the Update trigger.
Grant DELETE permissions to PUBLIC on the table. This is required to enable deleting rows from data access pages. Row-level security is enforced by the Delete trigger.
Row-Level Permissions Issues
When implementing row-level permissions, consider the following issues.
When the "Enable row permissions" option is selected for a main table, it applies to all its detail tables as well. Therefore, row permissions are enforced in all views Access Workflow Designer creates for the detail tables. In addition, the changes listed above are also applied to the detail table permissions.
Any changes made to base table permissions after the "Enable row permissions" option is selected are preserved.
When the "Enable row permissions" option is cleared, all row-level permissions associated with the table are deleted. No changes are made to table permissions. Therefore, when you disable row permissions, all roles that had access to some rows in the table can now access all the rows in the table.
Access Workflow Designer always grants SELECT permissions to PUBLIC on the base view created for each table.