• No results found

Properties

See “Configuration” on page 3-50.

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 “Pervasive 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.

³ To log out from a database

1 In Pervasive PSQL Explorer, expand the Engines node.

2 Expand the node for the registered server to display the databases on that server.

3 Right-click on the database from which you want to log out.

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”

„ “Directories”

„ “General”

„ “Relational Constraints”

„ “Security”

Code Page

This section details the property settings for Code Page.

„ “Database Code Page” on page 3-18

„ “PCC Connection Encoding” on page 3-19

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 data was entered using the encoding of the server or the client, as explained in “Encoding Interaction”

on page 10-16 in Getting Started With Pervasive PSQL.

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 Pervasive PSQL database engine and a client application. See “Encoding Interaction” on page 10-16 in Getting Started With Pervasive PSQL 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 pre-existing data or metadata in the database.

Database code page is particularly handy if you need to manually copy Pervasive 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.”

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” on page F-6 in SQL Engine Reference.

Directories

The property settings for Directories specify where certain types of files reside on physical storage.

„ “Dictionary Location” on page 3-20

„ “Data Directories” on page 3-20

PCC Connection Encoding Set to a Specific Encoding

PCC Connection Encoding Set to

"Automatic Translation"

PCC ignores “Database Code Page”

and uses the encoding specified to read and insert data and metadata.

(This is the legacy behavior of PCC.)

PCC and the database automatically establish compatible encoding.

The database metadata and data are translated from the encoding specified for “Database Code Page” to the encoding used on the system where PCC is running.

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 Linux, enter the standard Linux path format from root.

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” on page 3-20

„ “Integrity Enforced” on page 3-21

„ “Long Metadata (V2 metadata)” on page 3-21

„ “Relational Constraints” on page 3-21 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” on page 6-13.

Integrity Enforced

Specifies whether integrity constraints (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” on page 6-1 and “Interactions Between Btrieve and Relational Constraints” on page 6-11.

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” on page 6-11.

Security

Security contains property settings (tabbed areas) for Database Security and Btrieve Security. See the chapter “Pervasive PSQL Security” on page 7-1 for a complete discussion of security.