Defining Table Security

See Also

Team solution security is defined primarily using Microsoft Windows NTŪ and SQL Server. To add table and column permissions to your solution, you can use the security features available in Access or the SQL Server Enterprise Manager. For more information, see Security Permissions Model.

The Access Workflow Designer respects permissions on existing tables. However, when a main table has a primary key, SELECT permissions are granted to public on all the columns that make up the primary key. This is required for data access pages and any other clients using Microsoft Data Access Components (MDAC) to be able to send updates into the base table.

After the table has been registered in an Access Workflow Designer team solution, any subsequent permissions changes set by the user are preserved.

Table Permissions

Table permissions must be set through Access 2000 or SQL Server Enterprise Manager or by using OSQL, a command line utility that is available with Microsoft Data Engine (MSDE).

When a table is added to the table hierarchy using the Main Table Selection wizard, the permissions you want enforced on the selected table should be set on the view that is created on top of that table. The view will be named <tablename>View.

Existing table permissions are not replicated for the newly created view. If the table already has permissions, you must set them up again on the view.

For more information about setting table permissions, see the documentation for the application you are using to add the permissions.

Row-Level Permissions

Row-level permissions can be set only for main user tables. When you enable row-level permissions for your solution, a user can specify which roles have select, insert, update, and delete permissions on a per-row basis.

Detail tables automatically inherit permissions from the main table. Rows in detail tables automatically inherit permissions from the related row in the parent table. For example, in an order entry solution, if only users in the "OrderClerk" role can enter and view a customer order, the same would hold true for the related OrderDetails table.

For details, see Security Permissions Model and Enabling Row-Level Permissions.