Specifying the package contents
Published 06 February 2013
Whenever you package a database, SQL Packager requires information to connect to the database you want to package, and information about the database objects and data you want to include in that package. You enter this information using the SQL Packager Wizard.
The information you enter in the SQL Packager Wizard is saved in the current project. For more information about projects, see Working with projects.
Choosing the databases
If you have chosen to Package a database on the Choose a project type page, the Choose database to package page is displayed:
Alternatively, if you have chosen Package an upgrade to a database, the Choose databases to package into an upgrade page is displayed:
- In the relevant Server box, type or select the name of the SQL Server.
If you experience problems selecting a SQL Server that is not running on the LAN, for example if you are accessing the SQL Server via an internet connection, you may need to create an alias to the SQL Server using TCP/IP (refer to your SQL Server documentation for details). You can then type the alias name in the Server box to connect to the remote SQL Server.
To refresh the Server list, right-click the box and click Refresh, or scroll to the top of the list and click Refresh. - Select the authentication method, and for SQL Server authentication enter the User name and Password.
- In the Database box, type or select the database that you want to package.
To refresh the Database list, right-click in the box and click Refresh, or scroll to the top of the list and click Refresh. - If you are packaging an upgrade, in Database to upgrade enter the SQL Server and database details.
- Click Next. SQL Packager displays a message dialog box while it analyzes the database structure.
If you select the Close message box on completion check box, SQL Packager closes this message dialog box automatically the next time that you choose the databases. - If necessary, click OK to close the message box.
Choosing the database objects to package
If you are creating a package for a new database, SQL Packager lists the objects in the database that you can select for packaging.
If you are creating a package for upgrading an existing database, SQL Packager compares the previous version database with the latest version database to identify the changes to be made to the database structure to make the databases identical. SQL Packager lists the objects whose structure differs.
You select the objects to package by selecting or clearing the appropriate check boxes in the Package column. By default, the first time you run a project all objects are selected for packaging. To select all objects, click ; to clear all of the check boxes, click
You may see the following types of object:
Tables | User Defined Types | |||
Rules | Users | |||
Views | Functions | |||
Defaults | Roles | |||
Stored Procedures | Full Text Catalogs |
For SQL Server 2008 or SQL Server 2005, the following object types may also be shown:
Assemblies | Queues | |||
Asymmetric Keys | Routes | |||
Certificates | Schemas | |||
Contracts | Services | |||
DDL Triggers | Service Bindings | |||
Event Notifications | Symmetric Keys | |||
Message Types | Synonyms | |||
Partition Functions | XML Schema Collections | |||
Partition Schemes | Full Text Stoplist (SQL Server 2008 only) |
SQL Server 2008 and SQL Server 2005 severely restrict access to certificates, symmetric keys, and asymmetric keys. Consequently, SQL Packager can package only the permissions of certificates and asymmetric keys; symmetric keys cannot be packaged. To ignore all certificates, symmetric keys, and asymmetric keys, select the Ignore certificates, symmetric and asymmetric keys schema packaging option.
If you are upgrading a database, note that:
- Objects that are the same but have different owners are treated as different objects. For example, if a stored procedure exists in both databases and is identical except for its owner, it is considered to be a completely different object.
- For SQL Server 2000, differences in database-level permissions are not detected by SQL Packager. For example, if you have used SQL Server Enterprise Manager to set up permissions for your database, such as GRANT CONNECT or GRANT BACKUP, those permissions are not considered; however, permissions on objects are detected. If you want to include database-level permissions in your database package, you are recommended to use roles. For SQL Server 2008 and SQL Server 2005 differences in database-level permissions are detected.
- If the database contains an encrypted user-defined function, stored procedure, trigger, or view and you have system administrator permissions, SQL Packager decrypts the object and you can view its internal SQL in the schema packaging script. If you do not have system administrator privileges, the encrypted object cannot be displayed or upgraded.SQL Packager cannot decrypt views, stored procedures, functions, DML triggers, and DDL triggers that are encrypted in a SQL Server 2008 or SQL Server 2005 database. Therefore, SQL Packager cannot compare the objects; if an encrypted object exists in both databases, SQL Packager assumes that they are different, but will not be able to upgrade them.
- Stored procedures that are for replication are not compared or displayed.
- SQL Packager does not compare extended stored procedures.
For each object, the Action column indicates the action that will be taken on the object. If you are packaging a database to create a new one, the action will be Create for all objects. However, for an upgrade, note that the package does not only add new objects to the upgraded database; it may also Alter or Drop objects to make the databases identical.
If you are editing an existing project and the structure of the database has changed since you previously packaged it, you may need to click to update the page with the new structure.
When you have selected the objects that you want to package, click Next.
Choosing the data to package
SQL Packager lists the tables in the database for you to select for data packaging.
If you are creating a package for upgrading an existing database, you can select tables for data packaging only if they have:
- similar names
You can set SQL Packager so that it ignores the case of object names, and spaces or underscores in object names by using the data packaging options. - the same owner (case-sensitive)
- similar structures
- a primary key, unique index, or unique constraint that matches in both databases
SQL Packager uses the key, index, or constraint to determine which records correspond with each other. If more than one matching primary key, unique index, or unique constraint exists for a table, SQL Packager selects the most applicable (for example, a primary key is used in preference to a unique index).
You can also select a table for data packaging if it does not exist in the database you are upgrading, and you have chosen to package the table's structure in the previous page of the wizard.
You select the tables for data packaging by selecting or clearing the appropriate check boxes in the Package column. If you are creating a package for a new database, the package will insert data into the tables you have selected. However, for an upgrade, the package not only inserts data into tables, it may also update or delete rows to make the databases identical.
By default, the first time you run a project, all available tables are selected. To select all objects, click ; to clear all of the check boxes, click
If you are editing an existing project and the databases' data has changed since you previously packaged it, you may need to click to update the page.
When you have selected the tables for data packaging, click Next. SQL Packager displays a message dialog box while it generates the SQL script.
If you select the Close message box on completion check box, SQL Packager closes this message dialog box automatically the next time that it generates the SQL script.
If necessary, click OK to close the message box. The SQL scripts page of the Packager Wizard is displayed; for details, see Previewing the SQL scripts.