TRANSFER OWNERSHIP statement

The TRANSFER OWNERSHIP statement transfers ownership of a database object.

Invocation

This statement can be embedded in an application program or issued through the use of dynamic SQL statements. It is an executable statement that can be dynamically prepared only if DYNAMICRULES run behavior is in effect for the package (SQLSTATE 42509).

Authorization

The privileges held by the authorization ID of the statement must include at least one of the following authorities:

Ownership of the object
SECADM authority

Syntax

objects

alias-designator

function-designator

method-designator

procedure-designator

new-owner

Description

alias-designator

ALIAS alias-name

Identifies the alias that is to have its ownership transferred. The alias-name must identify an alias that is described in the catalog (SQLSTATE 42704). If PUBLIC is specified, the alias-name must identify a public alias that exists at the current server (SQLSTATE 42704).

FOR TABLE, or FOR SEQUENCE

Specifies the object type for the alias.

FOR TABLE: The alias is for a table, view, or nickname. When ownership of the alias is transferred, the value in the OWNER column for the alias in the SYSCAT.TABLES catalog view is replaced with the authorization ID of the new owner.
FOR SEQUENCE: The alias is for a sequence. When ownership of the alias is transferred, the value in the OWNER column for the alias in the SYSCAT.SEQUENCES catalog view is replaced with the authorization ID of the new owner.

CONSTRAINT table-name.constraint-name

Identifies the constraint that is to have its ownership transferred. The table-name.constraint-name combination must identify a constraint and the table that it constrains. The constraint-name must identify a constraint that is described in the catalog (SQLSTATE 42704).

When ownership of the constraint is transferred, the value in the OWNER column for the constraint in the SYSCAT.TABCONST catalog view is replaced with the authorization ID of the new owner.

If the constraint is a FOREIGN KEY constraint, the OWNER column in the SYSCAT.REFERENCES catalog view is replaced with the authorization ID of the new owner.
If the constraint is a PRIMARY KEY or UNIQUE constraint, the OWNER column in the SYSCAT.INDEXES catalog view for the index that was created implicitly for this constraint is replaced with the authorization ID of the new owner. If the index existed, and it is reused in this case, the owner of the index is not changed.

DATABASE PARTITION GROUP db-partition-group-name

Identifies the database partition group that is to have its ownership transferred. The db-partition-group-name must identify a database partition group that is described in the catalog (SQLSTATE 42704).

When ownership of the database partition group is transferred, the value in the OWNER column for the database partition group in the SYSCAT.DBPARTITIONGROUPS catalog view is replaced with the authorization ID of the new owner.

EVENT MONITOR event-monitor-name

Identifies the event monitor that is to have its ownership transferred. The event-monitor-name must identify an event monitor that is described in the catalog (SQLSTATE 42704).

When ownership of the event monitor is transferred, the value in the OWNER column for the event monitor in the SYSCAT.EVENTMONITORS catalog view is replaced with the authorization ID of the new owner.

If the identified event monitor is active, an error is returned (SQLSTATE 429BT).

If there are event files in the target path of a WRITE TO FILE event monitor whose ownership is being transferred, the event files are not deleted.

When ownership of WRITE TO TABLE event monitors is transferred, table information in the SYSCAT.EVENTTABLES catalog view is retained.

function-designator

Identifies the function that is to have its ownership transferred. For more information, see Function, method, and procedure designators. The specified function instance must be a user-defined function or function template that is described in the catalog. Ownership of functions that are implicitly generated by CREATE TYPE statements cannot be transferred (SQLSTATE 429BT).

When ownership of the function is transferred, the value in the OWNER column for the function in the SYSCAT.ROUTINES catalog view is replaced with the authorization ID of the new owner. Transferring ownership of an SQL function that has an associated package also implicitly transfers ownership of the package to the new owner.

SPECIFIC FUNCTION specific-name: Identifies the particular user-defined function that is to have its ownership transferred, using the specific name either specified or defaulted to at function creation time. In dynamic SQL statements, the CURRENT SCHEMA special register is used as a qualifier for an unqualified object name. In static SQL statements, the QUALIFIER precompile or bind option implicitly specifies the qualifier for unqualified object names. The specific-name must identify a specific function instance in the named or implied schema; otherwise, an error is returned (SQLSTATE 42704).
When ownership of the specific function is transferred, the value in the OWNER column for the specific function in the SYSCAT.ROUTINES catalog view is replaced with the authorization ID of the new owner.

FUNCTION MAPPING function-mapping-name

Identifies the function mapping that is to have its ownership transferred. The function-mapping-name must identify a function mapping that is described in the catalog (SQLSTATE 42704).

When ownership of the function mapping is transferred, the value in the OWNER column for the function mapping in the SYSCAT.FUNCMAPPINGS catalog view is replaced with the authorization ID of the new owner.

INDEX index-name

Identifies the index or index specification that is to have its ownership transferred. The index-name must identify an index or index specification that is described in the catalog (SQLSTATE 42704).

When ownership of the index is transferred, the value in the OWNER column for the index in the SYSCAT.INDEXES catalog view is replaced with the authorization ID of the new owner.

Ownership of an index cannot be transferred if the table on which the index is defined is a global temporary table (SQLSTATE 429BT).

INDEX EXTENSION index-extension-name

Identifies the index extension that is to have its ownership transferred. The index-extension-name must identify an index extension that is described in the catalog (SQLSTATE 42704).

When ownership of the index extension is transferred, the value in the OWNER column for the index extension in the SYSCAT.INDEXEXTENSIONS catalog view is replaced with the authorization ID of the new owner.

method-designator

Identifies the method that is to have its ownership transferred. For more information, see Function, method, and procedure designators. The method body specified must be a method that is described in the catalog (SQLSTATE 42704). The ownership of methods that are implicitly generated by the CREATE TYPE statement cannot be transferred (SQLSTATE 429BT).

When ownership of the method is transferred, the value in the OWNER column for the method in the SYSCAT.ROUTINES catalog view is replaced with the authorization ID of the new owner.

NICKNAME nickname

Identifies the nickname that is to have its ownership transferred. The nickname must be a nickname that is described in the catalog (SQLSTATE 42704).

When ownership of the nickname is transferred, the value in the OWNER column for the nickname in the SYSCAT.TABLES catalog view is replaced with the authorization ID of the new owner.

PACKAGE package-name

Identifies the package that is to have its ownership transferred. The package name must identify a package that is described in the catalog (SQLSTATE 42704).

VERSION version-id

Identifies which package version is to have its ownership transferred. If a value is not specified, the version defaults to the empty string, and the ownership of this package is transferred. If multiple packages with the same package name but different versions exist, only the ownership of the package whose version-id is specified in the TRANSFER OWNERSHIP statement is transferred. Delimit the version identifier with double quotation marks when it:

Is generated by the VERSION(AUTO) precompiler option
Begins with a digit
Contains lowercase or mixed-case letters

If the statement is invoked from an operating system command prompt, precede each double quotation mark delimiter with a back slash character to ensure that the operating system does not strip the delimiters.

When ownership of the package is transferred, the value in the BOUNDBY column for the package in the SYSCAT.PACKAGES catalog view is replaced with the authorization ID of the new owner.

The ownership of packages that are associated with SQL procedures, compiled SQL functions or compiled triggers cannot be transferred (SQLSTATE 429BT).

procedure-designator

Identifies the procedure that is to have its ownership transferred. For more information, see Function, method, and procedure designators. The procedure instance specified must be a procedure that is described in the catalog.

When ownership of the procedure is transferred, the value in the OWNER column for the procedure in the SYSCAT.ROUTINES catalog view is replaced with the authorization ID of the new owner.

Transferring ownership of an SQL procedure that has an associated package also implicitly transfers ownership of the package to the new owner.

SPECIFIC PROCEDURE specific-name: Identifies the particular procedure that is to have its ownership transferred, using the specific name either specified or defaulted to at procedure creation time. In dynamic SQL statements, the CURRENT SCHEMA special register is used as a qualifier for an unqualified object name. In static SQL statements, the QUALIFIER precompile or bind option implicitly specifies the qualifier for unqualified object names. The specific-name must identify a specific procedure instance in the named or implied schema; otherwise, an error is returned (SQLSTATE 42704).
When ownership of the specific procedure is transferred, the value in the OWNER column for the specific procedure in the SYSCAT.ROUTINES catalog view is replaced with the authorization ID of the new owner.

SCHEMA schema-name

Identifies the schema that is to have its ownership transferred. The schema-name must identify a schema that is described in the catalog (SQLSTATE 42704).

When ownership of the schema is transferred, the value in the OWNER column and the DEFINER column for the schema in the SYSCAT.SCHEMATA catalog view is replaced with the authorization ID of the new owner.

Ownership of built-in schemas (where the definer is SYSIBM) cannot be transferred (SQLSTATE 42832).

SEQUENCE sequence-name

Identifies the sequence that is to have its ownership transferred. The sequence-name must identify a sequence that is described in the catalog (SQLSTATE 42704).

When ownership of the sequence is transferred, the value in the OWNER column for the schema in the SYSCAT.SEQUENCES catalog view is replaced with the authorization ID of the new owner.

TABLE table-name

Identifies the table that is to have its ownership transferred. The table-name must identify a table that exists in the database (SQLSTATE 42704) and must not identify a declared temporary table (SQLSTATE 42995).

When ownership of the table is transferred:

The value in the OWNER column for the table in the SYSCAT.TABLES catalog view is replaced with the authorization ID of the new owner.
The value in the OWNER column for all dependent objects on the table in the SYSCAT.TABDEP catalog view is replaced with the authorization ID of the new owner.

Ownership of subtables in a table hierarchy cannot be transferred (SQLSTATE 429BT).

In a federated system, ownership of a remote table that was created using transparent DDL can be transferred. Transferring the ownership of a remote table will not transfer ownership of the nickname that is associated with the table. Ownership of such a nickname can be transferred explicitly using the TRANSFER OWNERSHIP statement.

TABLE HIERARCHY root-table-name

Identifies the typed table that is the root table in a typed table hierarchy that is to have its ownership transferred. The root-table-name must identify a typed table that is the root table in the typed table hierarchy (SQLSTATE 428DR), and must refer to a typed table that exists in the database (SQLSTATE 42704).

When ownership of the table hierarchy is transferred:

The value in the OWNER column for the root table and all of its subtables in the SYSCAT.TABLES catalog view is replaced with the authorization ID of the new owner.
The value in the OWNER column for all dependent objects on the table and all of its subtables in the SYSCAT.TABDEP catalog view is replaced with the authorization ID of the new owner.

TABLESPACE tablespace-name

Identifies the table space that is to have its ownership transferred. The tablespace-name must identify a table space that is described in the catalog (SQLSTATE 42704).

When ownership of the table space is transferred, the value in the OWNER column for the table space in the SYSCAT.TABLESPACES catalog view is replaced with the authorization ID of the new owner.

TRIGGER trigger-name

Identifies the trigger that is to have its ownership transferred. The trigger-name must identify a trigger that is described in the catalog (SQLSTATE 42704).

When ownership of the trigger is transferred, the value in the OWNER column for the trigger in the SYSCAT.TRIGGERS catalog view is replaced with the authorization ID of the new owner. Transferring ownership of a compiled trigger also implicitly transfers ownership of the associated package to the new owner.

TYPE type-name

Identifies the user-defined type that is to have its ownership transferred. The type-name must identify a type that is described in the catalog (SQLSTATE 42704). If DISTINCT is specified, type-name must identify a distinct type that is described in the catalog (SQLSTATE 42704).

In dynamic SQL statements, the CURRENT SCHEMA special register is used as a qualifier for an unqualified object name. In static SQL statements, the QUALIFIER precompile or bind option implicitly specifies the qualifier for unqualified object names.

When ownership of the type is transferred, the value in the OWNER column for the type in the SYSCAT.DATATYPES catalog view is replaced with the authorization ID of the new owner.

TYPE MAPPING type-mapping-name

Identifies the user-defined data type mapping that is to have its ownership transferred. The type-mapping-name must identify a data type mapping that is described in the catalog (SQLSTATE 42704).

When ownership of the type mapping is transferred, the value in the OWNER column for the type mapping in the SYSCAT.TYPEMAPPINGS catalog view is replaced with the authorization ID of the new owner.

VARIABLE variable-name

Indicates that the object whose ownership is to be transferred is a created global variable. The variable-name must identify a global variable that exists at the current server (SQLSTATE 42704).

When the global variable is transferred, the value in the OWNER column for the global variable in the SYSCAT.VARIABLES catalog view is replaced with the authorization ID of the new owner.

VIEW view-name

Identifies the view that is to have its ownership transferred. The view-name must identify a view that exists in the database (SQLSTATE 42704).

When ownership of the view is transferred:

The value in the OWNER column for the view in the SYSCAT.VIEWS catalog view is replaced with the authorization ID of the new owner.
The value in the OWNER column for all dependent objects on the view in the SYSCAT.TABDEP catalog view is replaced with the authorization ID of the new owner.

The ownership of a subview in a view hierarchy cannot be transferred (SQLSTATE 429BT).

VIEW HIERARCHY root-view-name

Identifies the typed view that is the root view in a typed view hierarchy that is to have its ownership transferred. The root-view-name must identify a typed view that is the root view in the typed view hierarchy (SQLSTATE 428DR), and must refer to a typed view that exists in the database (SQLSTATE 42704).

When ownership of the view hierarchy is transferred:

The value in the OWNER column for the root view and all of its subviews in the SYSCAT.VIEWS catalog view is replaced with the authorization ID of the new owner.
The value in the OWNER column for all dependent objects on the view and all of its subviews in the SYSCAT.TABDEP catalog view is replaced with the authorization ID of the new owner.

XSROBJECT xsrobject-name

Identifies the XSR object that is to have its ownership transferred. The xsrobject-name must identify an XSR object that is described in the catalog (SQLSTATE 42704).

When ownership of the XSR object is transferred, the value in the OWNER column for the XSR object in the SYSCAT.XSROBJECTS catalog view is replaced with the authorization ID of the new owner.

USER authorization-name

Specifies the authorization ID to which ownership of the object is being transferred.

SESSION_USER

Specifies that the value of the SESSION_USER special register is to be used as the authorization ID to which ownership of the object is being transferred.

SYSTEM_USER

Specifies that the value of the SYSTEM_USER special register is to be used as the authorization ID to which ownership of the object is being transferred.

REVOKE PRIVILEGES

Indicates that the old owner of an object will lose all privileges on the object being transferred. This is the default option.

PRESERVE PRIVILEGES

Specifies that the current owner of an object that is to have its ownership transferred will continue to hold any existing privileges on the object after the transfer. For example, any privileges that were granted to the creator of a view when that view was created continue to be held by the original owner even after ownership has been transferred to another user.

Rules

Ownership of most built-in objects (where the owner is SYSIBM) cannot be transferred (SQLSTATE 42832). However, you can transfer ownership of implicitly created schema objects that have SYSIBM in the OWNER column and do not have SYSIBM in the DEFINER column.
Ownership of schemas whose name starts with 'SYS' cannot be transferred (SQLSTATE 42832).
Ownership of the following objects cannot be explicitly transferred (SQLSTATE 429BT):
- Subtables in a table hierarchy (they are transferred with the root hierarchy table)
- Subviews in a view hierarchy (they are transferred with the root hierarchy view)
- Indexes that are defined on global temporary tables
- Methods or functions that are implicitly generated when a user-defined type is created
- Module aliases and modules
- Packages that depend on SQL procedures (they are transferred with the SQL procedure)
- Event monitors that are active (they can be transferred when they are not active)
An authorization ID that has SECADM authority cannot transfer the ownership of an object to itself, if it is not already the owner of the object (SQLSTATE 42502).
Transfer of ownership on a variable or sequence with REVOKE PRIVILEGES will fail if any objects depend on the privileges being revoked (SQLSTATE 42893).
Transfer of ownership on a function with REVOKE PRIVILEGES on a routine will fail if both of the following conditions are true (SQLSTATE 42893)
- The specified routine is used in a view, trigger, constraint, index extension, SQL function, SQL method, transform group, or is referenced as the SOURCE of a sourced function.
- The loss of the EXECUTE privilege would cause the owner of the view, trigger, constraint, index extension, SQL function, SQL method, transform group, or sourced function to no longer be able to execute the specified routine.
Transfer of ownership on a module, table, view, nickname, or routine with REVOKE PRIVILEGES will cause any dependent view, MQT, function, trigger, and package to marked inoperative or invalid unless the old owner has the revoked privileges through a database authority or schema authority or through a group, role, or PUBLIC.

Notes

All privileges that the current owner has that were granted as part of the creation of the object are transferred to the new owner. If the current owner has had a privilege on the object revoked, and that privilege was subsequently granted back, the privilege is not transferred. For implicitly created schema objects that have not already been transferred, the new owner is granted CREATEIN, DROPIN, and ALTERIN on the schema and can also grant only these privileges to other users.

When the ownership of a database object is transferred, the new owner must have the set of privileges on the base objects, as indicated by the object's dependencies, that are required to maintain the object's existence unchanged. The new owner does not need the privileges required to create the object if those privileges are not required to maintain the object's existence.

For example:

Consider a view with SELECT and INSERT dependencies on an underlying table. The privileges held by the new owner of the view must include at least SELECT (with or without the GRANT OPTION) and INSERT (with or without the GRANT OPTION) for the ownership transfer to be successful. If the dependencies were SELECT WITH GRANT OPTION and INSERT WITH GRANT OPTION, the privileges held by the new owner of the view must include at least SELECT WITH GRANT OPTION and INSERT WITH GRANT OPTION.
Consider a view with a dependency on a routine. The privileges held by the new owner of the view must include at least EXECUTE on the dependent routine.
Consider a trigger with a dependency on a table. The privileges held by the new owner of the trigger must include the same set of privileges on the table that are indicated by the trigger's dependencies. ALTER privilege on the table on which the trigger is defined is not required.

The following table lists the catalog views that describe the objects on which other database objects depend.

Table 1. Catalog Views that Describe Objects on which Other Objects Depend
Database Object	Catalog View
CONSTRAINT	SYSCAT.CONSTDEP
FUNCTION	SYSCAT.ROUTINEDEP; SYSCAT.ROUTINES (for a sourced function)
INDEX	SYSCAT.INDEXDEP
INDEX EXTENSION	SYSCAT.INDEXEXTENSIONDEP
METHOD	SYSCAT.ROUTINEDEP
PACKAGE	SYSCAT.PACKAGEDEP
PROCEDURE	SYSCAT.ROUTINEDEP
TABLE	SYSCAT.TABDEP
TRIGGER	SYSCAT.TRIGDEP
VIEW	SYSCAT.TABDEP
XSROBJECT	SYSCAT.XSROBJECTDEP

If ownership of a database object that depends on another object is to be transferred successfully, the new owner of the database object must hold certain privileges on the dependent object of that dependency:

If the dependent object is a sequence, the new owner must have the USAGE privilege on that sequence.
If the dependent object is a function, method, or procedure, the new owner must have the EXECUTE privilege on that function, method, or procedure.
If the dependent object is a package, the new owner must have the EXECUTE privilege on that package.
If the dependent object is an XSR object, the new owner must have the USAGE privilege on that XSR object.

For any other dependent object of a dependency, use the TABAUTH column in the appropriate catalog view to determine what privileges the new owner must hold.

If an attempt is made to transfer ownership of an object to its owner, a warning is returned (SQLSTATE 01676).
Ownership of the following database objects cannot be transferred, because these objects have no owner: audit policies, buffer pools, roles, security labels, security label components, security policies, servers, transformation functions, trusted contexts, user mappings, and wrappers. Note that there is no OWNER column in the SYSCAT.AUDITPOLICIES, SYSCAT.BUFFERPOOLS, SYSCAT.CONTEXTS, SYSCAT.ROLES, SYSCAT.SECURITYLABELS, SYSCAT.SECURITYLABELCOMPONENTS, SYSCAT.SECURITYPOLICIES, SYSCAT.SERVERS, SYSCAT.TRANSFORMS, SYSCAT.USEROPTIONS, and SYSCAT.WRAPPERS catalog views.
The schema name of an object whose ownership was transferred does not automatically change.
Syntax alternatives: For consistency with other SQL statements:
- NODEGROUP can be specified in place of DATABASE PARTITION GROUP
- SYNONYM can be specified in place of ALIAS

Examples

Example 1: Transfer ownership of table T1 to PAUL.
```
   TRANSFER OWNERSHIP OF TABLE WALID.T1
     TO USER PAUL PRESERVE PRIVILEGES
```
The value in the OWNER column for the table WALID.T1 in the SYSCAT.TABLES catalog view is replaced with 'PAUL'. Paul is implicitly granted the following privileges on table WALID.T1 (assuming that the previous owner of the table did not lose any privileges on it): CONTROL and ALTER, DELETE, INDEX, INSERT, SELECT, UPDATE, REFERENCE (WITH GRANT OPTION).
Example 2: Assume that JOHN creates tables T1 and T2, and that MIKE holds SELECT privilege on tables JOHN.T1 and JOHN.T2. MIKE creates view V1 that depends on tables JOHN.T1 and JOHN.T2. Transfer ownership of view V1 to HENRY, who has DBADM authority.
```
   TRANSFER OWNERSHIP OF VIEW V1
     TO USER HENRY PRESERVE PRIVILEGES
```
The value in the OWNER column for the view V1 in the SYSCAT.VIEWS catalog view is replaced with 'HENRY'. A new row is added to SYSCAT.TABAUTH with the following values: GRANTOR = 'SYSIBM', GRANTEE = 'HENRY', and TABNAME = 'V1'.
Example 3: Assume that HENRY, who holds DBADM authority, creates a trigger TR1 that depends on table T1. Transfer ownership of trigger TR1 to WALID, who does not hold DBADM authority.
```
   TRANSFER OWNERSHIP OF TRIGGER TR1
     TO USER WALID PRESERVE PRIVILEGES
```
Ownership of the trigger is transferred successfully, even though Walid does not hold DBADM authority.
Example 4: Assume that JOHN creates tables T1 and T2, and that MIKE holds SELECT privilege on table JOHN.T1 and CONTROL privilege on table JOHN.T2. PAUL holds SELECT privilege on tables JOHN.T1 and JOHN.T2. MIKE creates view V1 that depends on tables JOHN.T1 and JOHN.T2. The view has an entry for the SELECT privilege in SYSCAT.TABAUTH and two SELECT dependencies in SYSCAT.TABDEP for tables JOHN.T1 and JOHN.T2. Transfer ownership of view V1 to PAUL, who is a regular user.
```
   TRANSFER OWNERSHIP OF VIEW V1
     TO USER PAUL PRESERVE PRIVILEGES
```
Ownership of the view is transferred successfully, even though Paul does not hold CONTROL privilege on table JOHN.T2. Paul only needs SELECT privilege on tables JOHN.T1 and JOHN.T2 to maintain the view's existence. (The view only has SELECT privilege because Paul did not hold CONTROL privilege on both tables when the view was created and, as a result, he was not granted CONTROL on the view.) The value in the OWNER column for the view V1 in the SYSCAT.VIEWS catalog view is replaced with 'PAUL'. The value in the OWNER column for the view V1 in the SYSCAT.TABDEP catalog view is replaced with 'PAUL'. A new row is added to SYSCAT.TABAUTH with the following values: GRANTOR = 'SYSIBM', GRANTEE = 'PAUL', and TABNAME = 'V1'.
Example 5: Assume that JOHN creates table T1, and that PUBLIC holds SELECT privilege on JOHN.T1. PAUL holds SELECT privilege on JOHN.T1 explicitly, and creates view V1 that depends on table JOHN.T1. Transfer ownership of view V1 to MIKE, who is not a DBADM, but who holds the required privileges to acquire view ownership through the special group PUBLIC.
```
   TRANSFER OWNERSHIP OF VIEW V1
     TO USER MIKE PRESERVE PRIVILEGES
```
Ownership of the view is transferred successfully, because Mike holds SELECT privilege on table JOHN.T1 through PUBLIC. The value in the OWNER column for the view V1 in the SYSCAT.VIEWS catalog view is replaced with 'MIKE'. The value in the OWNER column for the view V1 in the SYSCAT.TABDEP catalog view is replaced with 'MIKE'. A new row is added to SYSCAT.TABAUTH with the following values: GRANTOR = 'SYSIBM', GRANTEE = 'MIKE', and TABNAME = 'V1'.
Example 6: Similar to example 5, assume that JOHN creates table T1, and that role R1 holds SELECT privilege on JOHN.T1. PAUL holds SELECT privilege on JOHN.T1 explicitly, and creates view V1 that depends on table JOHN.T1. Transfer ownership of view V1 to MIKE, who is not a DBADM, but who holds the required privileges through membership in role R1 to acquire view ownership.
```
   TRANSFER OWNERSHIP OF VIEW V1
     TO USER MIKE PRESERVE PRIVILEGES
```
Ownership of the view is transferred successfully, because Mike holds SELECT privilege on table JOHN.T1 through membership in role R1. The value in the OWNER column for the view V1 in the SYSCAT.VIEWS catalog view is replaced with 'MIKE'. The value in the OWNER column for the view V1 in the SYSCAT.TABDEP catalog view is replaced with 'MIKE'. A new row is added to SYSCAT.TABAUTH with the following values: GRANTOR = 'SYSIBM', GRANTEE = 'MIKE', and TABNAME = 'V1'.