1.To edit an SQL database object, users load the list of existing items by calling the SQL Databases view within the Visual Designer mode of PackDesigner.
2.Clicking on the list item of the object that has to be modified displays its details in the editor panel on the right-hand side of the RayPack application screen.
The following properties of the SQL database object may be manipulated:
Database Name
The database name is displayed above the three view tabs of the edit area. It becomes editable with a click on either the name itself, or the edit icon on the right-hand side. A direct value editor dialog is displayed, allowing to enter the new name value. By hitting Enter or clicking on the save icon within the direct value editor interface the new name is saved.
Tab: CONNECTION
Server
The physical address of the database server. This property is mandatory. It may either be defined by directly entering a string value of max. 255 characters length, or by using one of the variables available within the packaging project (e. g. a property). To trigger support for dynamic content input, users have to type an opening square bracket. The dialog for MSI formatted string input fields is displayed. Please refer to the common dialogs section for further details on how to handle this type of input control.
Instance
The instance name of the target SQL database object. If this optional value is not set, the default instance of the specified database server will be addressed.
The square brackets at the right-hand side of the input field indicate, that it is a special input field, allowing packagers to use Properties and other variable packaging project information for the value definition. Please refer to the MSI formatted string field section for further details on how to handle this typical kind of user interface control in RayPack.
Component
Each SQL database object has to be related to a component item of the packaging project. RayPack automatically creates a new component when an SQL database item is created. However, it is possible to change the predefined component structure.
To select another existing component as parent object of the SQL database item, users click on the downwards-pointing arrow at the right-hand side of the component selector control. A list of existing components is displayed. The new setting is established with a click on any of the given components.
To create a new component for the SQL database object, users click on the browse button [...] at the right-hand side of the component control. The common dialog type Select Component is displayed, ready for creating and selecting components.
User
The credentials used to connect to the specified SQL database may be provided by denoting a user profile. To change the current user profile relation, packagers click on the browse button [...] at the right-hand side of the user property control object. The common dialog Select User is displayed, ready for creating, editing, removing and mere selecting of user profiles. Please refer to the section User object manager to get more details about the handling of this interface type.
|
Be aware: User objects may very likely be used at several places within SQL database, script, and IIS management structures. When the same user item is referred to from different locations, changing the properties of that user item actually takes effect for all related objects. Please double-check the correctness of user profile changes, and make sure all related objects are still valid and operational with the modified set of properties. |
Tab: ADVANCED
Run-time behavior
This steps allows to determine the activities performed during the several run-times of a typical Windows Installer package:
•On install
•On uninstall
•On reinstall
It is possible to independently determine if the database object should be created, dropped, or not affected at all during a specific run-time type. A typical setting would be to create the database on install, execute no action on uninstall, and create on reinstall.
Continue on error
When this checkbox is activated, errors that occur during the activities defined above do not lead to a package run-time execution to fail. It is recommended to keep it de-activated (as it is per default), if a database is vital for the operability of other package resources.
Confirm updates of existing databases
If the database already exists on the target device, activating this checkbox demands user confirmation for any action that manipulates the existing database at package run-time.
If the checkbox is not active, manipulations of existing databases will be executed without explicit user confirmation. It is highly recommended to double-check the expected and actual run-time behavior of the target package in order to prevent data loss and negative user experience.
Tab: FILE SPECIFICATIONS
If the SQL database object is actually used to create a new database on the package target machines, it is possible to define properties for the database files and log files:
Create File Specification
If this option is active, the following file related settings become effective and will be considered during the SQL database creation phase.
The destination of the newly created database file has to be defined by selecting one of the already given directories within the packaging project, or by creating a new one. Both procedures may be done by clicking the browse button [...] at the right-hand side of the destination folder property control item, and using the interface of the common dialog Select directory.
The name of the database file has to be given with the Microsoft SQL database standard extension *.mdf. A default name is derived from the value entered as database name, and the suffix "_DB". It is recommended to follow a definitive file name convention to prevent accidental removal or manipulation of vital resources.
The initial size of the file. The entered value may be extended with the suffixes KB, MB, and GB. If no suffix is provided, the value will be considered to be given in MB. If this optional property is not defined, a default of 1MB initial size is actually applied to the file.
When the initial file size does no longer suffice to manage the required amount of data, the growth size determines the steps for file enlargements:
•If a value is given without one of the possible suffixes KB, MB, GB, or %, the value is considered to be given in MB.
•If no value is given, the default growth step is 10%.
•A growth step may not be smaller than 64KB
•A growth step may not be larger than the max. file size (see below)
In order to prevent the database from overpopulating the parent device, it is recommended to define a maximal size for the database content. The entered value may be extended with the suffixes KB, MB, and GB. If no suffix is provided, the value will be considered to be given in MB. If this optional property is not defined, the file may grow until the available disk space is fully consumed.
Create Log File Specification
If this option is active, the following log file related settings become effective and will be considered during the SQL database creation phase.
Destination folder
See above.
File name
The name of the log file has to be given with the Microsoft SQL database standard extension *.ldf. A default name is derived from the value entered as database name, and the suffix "_DBLog". It is recommended to follow a definitive file name convention to prevent accidental removal or manipulation of vital resources.
Size
See above.
Growth size
See above.
Max size
See above.