Users with the Clone Administration privilege can designate SQL scripts to run on newly cloned databases. Post-clone scripts automate common tasks such as removing sensitive user data or adding, updating, or removing tables.

Data Director does not provide out-of-the-box SQL scripts. You develop, test, and maintain post-clone SQL scripts.

You can associate multiple post-clone scripts with a database, but only one of the database's associated post-clone scripts can be active. The active (default) post-clone script runs immediately following the clone database operation. Users with the Clone Administration privilege can choose which post-clone script to run after a particular clone operation.

Users with the Clone Administration privilege can choose a post-clone script failure action.

Delete the cloned database if the post-clone script fails and log an error, or

Allow the clone operation to finish and log a warning.

Users who do not have the Clone Administration privilege might not know that a post-clone script is associated with a database unless an error occurs. These users cannot choose the script to run, and cannot choose a post-clone script failure action. If the database has a default post-clone script, that script runs automatically. If the post-clone script fails, the clone is deleted. The user receives a notice that the clone failed because the post-clone script failed. The user is instructed to check with the database owner for details.

When a post-clone script fails, Data Director logs an error event or a warning event against the source database.

If a user without the Clone Administration privilege attempts the clone operation or the clone administrator chooses to delete the clone if the post-clone script fails, the event is logged as an error.

If a clone administrator attempts the clone operation and chooses to allow the clone operation to finish if the post-clone script fails, the event is logged as a warning.

The event contains information about the operation that failed and the user who attempted the clone operation. Users with the View and Monitor privilege on the source database can view the event.

Organization administrators and users with Clone Administration privileges can author a SQL script to run as the last step in the clone database process.

Organization administrators and users with Clone Administration privileges can designate a SQL script to run after a database is cloned by adding a SQL script to a database's cloning properties.

Organization administrators or users with Clone Administration privileges can edit post-clone scripts, for example, when there are updates to database schema.

Organization administrators and users with Clone Administration privileges can save post-clone SQL scripts to a location outside Data Director.

You can associate multiple post-clone scripts with a database, but only one can be active. Organization administrators and users with Clone Administration privileges can choose one post-clone script as the active (default) script.

Users with Clone Administration privileges can delete post-clone scripts, for example, when the scripts become obsolete. You cannot delete active scripts.