Databases
A database is a collection of data stored together. Newly created databases are empty and may be populated with tables. Refer to the chapter PSQL Databases in Advanced Operations Guide for a detailed discussion of databases.
The properties of a database include such items as file locations, referential constraints, security, and whether the database is bound.
*Note: If you wish to add a database to a Server engine, you must have administrative rights on the server operating system. If you do not have administrative rights, you will not be permitted to add the database.
1
2
3
4
Click Logout (name).
Name reflects the name of the user currently logged in to the database. If the database does not have security enabled, name is Master. Name may also be Master if the current user is logged in as Master.
Any nodes expanded for the database are collapsed.
Database Properties
You set properties for a database from a Properties dialog in PCC. The dialog contains a tree with the following property nodes:
Code Page
This section details the property settings for Code Page.
*Note: The database engine does not validate the encoding of the data and metadata that an application inserts into a database. The engine assumes that all text data was translated by the client to the encoding of the server or the client database code page, as explained in Database Code Page and Client Encoding in Advanced Operations Guide.
Database Code Page
This property specifies the encoding to use for metadata and is stored in DBNAMES.cfg. Note that this property applies to the database, which means that it potentially affects all client applications that exchange data with that database. A compatible encoding must be established between the PSQL database engine and a client application. See Database Code Page and Client Encoding in Advanced Operations Guide for the various ways in which this can be accomplished.
*Note: Changing the database code page does not convert existing data or metadata in the database. To avoid data corruption, ensure that the code page setting matches the current encoding of any preexisting data or metadata in the database.
Database code page is particularly handy if you need to manually copy PSQL DDFs to another platform with a different OS encoding and still have the metadata correctly interpreted by the database engine.
The default code page is “server default,” meaning the operating system code page on the server where the database engine is running. The link “Change code page” provides additional information about the setting and lets you select a specific code page.
PCC Connection Encoding
PCC is, itself, a client application to the database engine. As a client, PCC lets you specify the code page (the encoding) to use for each database session when PCC reads and inserts metadata and data. The default for an existing database is to use the encoding of the machine where PCC is running. This is the legacy behavior of PCC. The default for a new database is to use automatic translation.
The following explains the interaction between the settings for PCC Connection Encoding and Database Code Page.
PCC ignores Database Code Page and uses the encoding specified to read and insert data and metadata.
*Note: PCC Connection Encoding applies only to PCC. It has no affect on other client applications.
When a database has OEM character data in it, the legacy solution was for the access method, such as ODBC using a DSN, to specify OEM/ANSI conversion. Now it is possible to set the OEM code page for the database and have the access method specify automatic translation. See also Automatic in ODBC Guide.
Directories
The property settings for Directories specify where certain types of files reside on physical storage.
Dictionary Location
This location specifies where the dictionary files (DDFs) reside on physical storage. This location must be on the same server to which you are connected and where the database engine is running. The location must be formatted as though you are working directly at the server machine.
For Windows operating systems, enter a path in the form drive:\path, where drive is a drive letter on the server.
For example, if you are at a workstation connected to a Windows server where the database engine is running, and you want to create a new database on the C:\ drive of the server in the folder mydata, enter the location as c:\mydata. You would enter it this way even if you have a local network drive (for example, F:\) mapped to the server’s C:\ drive.
Data Directories
The Data Directories list specifies where the data files reside on physical storage. Add locations to the list by clicking New. Remove lets you remove locations from the list. The locations must be on the same server where the database engine is running.
Specify the location in the same manner as for the dictionary locations.
General
General contains the following property settings:
Bound Database
Indicates whether or not the database is bound. Binding a database prevents the DDFs or data files from being used in another database and prevents a data file from having two or more different table definitions within the same database.
For more information about bound databases, refer to Bound Database versus Integrity Enforced.
Integrity Enforced
Specifies whether integrity constraints, such as security, RI, and triggers, are enforced on the database. These constraints apply to Btrieve access to the data files as well as ODBC/SQL access.
See Setting Up Referential Integrity and Interactions Between Btrieve and Relational Constraints.
Long Metadata (V2 metadata)
This property is read-only and shows whether V2 metadata was specified when the database was created. If it was, the Long Metadata option is selected. Note that V2 metadata is also referred to as “long metadata.”
Relational Constraints
Relational Constraints displays a matrix that lists the relational constraints in effect for the database. See Interactions Between Btrieve and Relational Constraints.
Security
Security contains property settings (tabbed areas) for Database Security and Btrieve Security. See the chapter PSQL Security for a complete discussion of security.