PSQL Control Center (PCC) is a graphical tool for creating and managing databases and controlling your database engine. It allows you to access nearly all the functions of the product from one place. The following topics lead you on a tour of PCC to learn its interface and common operations.

PSQL Control Center (PCC) is an integrated framework in which users can connect to PSQL engines, set up and modify databases and tables, query and update data, tune engine performance, and access the PSQL documentation library.

PCC uses a file explorer motif – a tree of objects – referred to as PSQL Explorer. This tree can be expanded to reveal detail. Examples of objects include engines, databases, tables, and users. The following figures illustrate PCC with several tabbed views displayed. PSQL Explorer is on the left.

Depending on the Linux distribution or if you are using Mac OS, the appearance of PCC may differ, but functionality is the same.

On Windows platforms, PCC is installed by default when you install a database engine or a client. See PSQL Optional Features in Getting Started with PSQL.

On Linux and macOS, PCC is included in the full installation. See Full and Client Installations on Linux, macOS, and Raspbian in Getting Started with PSQL.

Access Control Center from the operating system Start menu or Apps screen. You may also run the executable file pcc.exe.

Start PCC by running the executable script file pcc from a command prompt. The script file is located, by default installation, in the usr/local/psql/bin directory.

We recommend that you start PCC from a command prompt and not by double-clicking the script file using a file browser application. See Table Table 5, Troubleshooting Guide for Running PCC.

The following requirements must be met to start PCC on Linux.

If you have met the requirements to run PCC and still are having difficulty running the utility, refer to the following troubleshooting guide.

On macOS, only the user logged in to the Desktop can start PCC. Open Finder and then Applications > Actian PSQL > PSQL Control Center.

For efficiency, PCC caches certain information. The cache must be cleared after you install or upgrade products that interact with PCC so that the change appears in PSQL Explorer. For example, if you were to install or upgrade DataExchange, you would then need to clear the PCC cache.

The cache can be cleared only by starting PCC with a parameter from the command line.

The PCC main window offers various editors and views:

You can display and work with objects through the different editors and views. Multiple editors of the same type, such as SQL Editor, can be open at the same time. Each object being edited is represented by a tab on top of the editor. The tab contains the name of the object. Data modified within an editor must be explicitly saved (for example, with File > Save).

Views, such as PSQL Explorer, can be opened only one at a time. Your actions within a view are applied immediately, without your having to save them.

The following table summarizes the characteristics of the editors and views.

This view displays a tree of objects of various types and enables you to do many tasks.

The tree of objects includes a root node named PSQL. The root node contains objects such as clients, services (if applicable), database engines, databases, tables, views, stored procedures, user-defined functions, triggers, groups, users, and system objects (such as system tables).

Most objects in PSQL Explorer can be expanded to reveal more detail. Click the expand icon to the left of an object to see objects under it. The expand icon may be a plus sign “+”, a triangle “”, or some other similar symbol. The collapse icon appears after you click an expand icon. Click the collapse icon to hide subordinate objects.

If properties (configurable settings) apply to an object, you can access them by right-clicking an object and selecting Properties. You can also click an object then press Alt+Enter to display properties. See also Configuration Reference in Advanced Operations Guide.

In addition to accessing properties, numerous other tasks can be invoked from PSQL Explorer by right-clicking an object. The following table summarizes the tasks.

SQL Editor allows you to run Structured Query Language (SQL) statements against a PSQL database. See SQL Editor for a detailed discussion.

The Grid window view shows in a matrix format, like a spreadsheet, the result of running SQL statements. Each field is represented as a column and the data appears in cells within the columns. You can change data directly in the Grid cells as well as add additional rows to the Grid.

Both Table Editor and SQL Editor use the Grid. See To view table data while using Table Editor and Grid Window View for further details.

The Text window view shows in a text format the result of running SQL statements. The text is display only. You cannot change data values by changing the text, but you can copy text. See Text Window View for a detailed discussion.

The Outline window view allows you to view the SQL statements in a tree structure. The root node of the tree is the same name as the name of the SQL Editor window view. See Outline Window View for a detailed discussion.

Note that the editor must support an outline or the Outline window view is not available. Currently, only SQL Editor supports an outline view.

Table Editor allows you to add, delete, or change the characteristics of columns within a table. The table may be one newly created or an existing table that you want to edit. See Table Editor for a detailed discussion.

You can set general preferences for your experience in PCC. You can also set preferences for the window views in PCC or for the external tools.

The following are the options that can be set in the General Preferences:

Select Always remove associated DSN entries to have all DSN entries for any database automatically deleted along with the database without prompting.

Clear Do not prompt for new database each time a SQL document is opened to be prompted to select a database each time you open a SQL document in the SQL Editor. If this option is deselected, select it to use the most recently selected database when you open a SQL document. The selected database is not maintained across PCC sessions. If you close and reopen PCC, you will have to select a new default database context.

You can set preferences for the following PCC window views:

The preference setting for File Encoding allows you to work more easily with files containing wide character data. This setting provides the following features:

Some utilities have not yet been tightly integrated within the PCC framework. However, they may still be started from within PCC by selecting them through the Tools menu:

You can add your own software programs to the PCC Tools menu.

PCC offers a convenient way to work with PSQL servers on Windows machines without having to use the Windows Services control panel. You can start, stop, and set the startup policy from within PCC.

You must stop the relational and transactional services to completely stop PSQL. Stopping just one of the services does not stop the database engine completely.

This section applies only to Windows platforms, not to Linux.

See To use PCC to set services startup policy in Advanced Operations Guide.

You can use PCC to work with database engines that are on your machine or with remote server engines. To work with a remote server engine, you must introduce it to PCC. This procedure is called registering the server.

Your local server is automatically registered to PCC when you install PSQL. The local server appears in the PSQL Explorer as the first entry under the Engines node.

See Configuring Database Engines and Clients.

PCC provides Capacity Usage Viewer to monitor concurrent sessions and data usage for all database engines. This is especially useful when you are considering migrating between PSQL engines that use different license models.

See Capacity Usage Viewer in Advanced Operations Guide.

PCC integrates a Monitor utility which allows you to monitor certain activities and attributes of the database engine. The utility can monitor aspects of the MicroKernel Engine and the Relational Engine. It presents information organized into a series of tabs, that can be rearranged for your convenience, with columns of data that can rearranged and sorted. It presents a snapshot of a particular moment and can be refreshed either manually or automatically.

See Monitoring Database State in Advanced Operations Guide.

PCC provides the Defragmenter utility to enable you to detect data file fragmentation that may be causing loss of engine performance. Defragmenter also enables you to correct the fragmentation by rearranging records that have become out of order and removing unused space left by deletions. Defragmenting a file does not alter its data in any way, and records can be created, read, updated, or deleted while the files that store them are being defragmented. You can use Defragmenter features during database engine execution with no need for down time or disruption of business operations in most cases.

See Monitoring Data File Fragmentation in Advanced Operations Guide.

A database is a collection of data stored together. Newly created databases are empty and may be populated with tables. See PSQL Databases in Advanced Operations Guide for a detailed discussion.

The properties of a database include such items as file locations, referential constraints, security, and whether the database is bound.

You set properties for a database from a Properties dialog in PCC. This window lists the following property nodes:

This section details the property settings for 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.

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

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.

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

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 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 C:\ drive on the server.

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 contains the following property settings:

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 more than one table definition within the same database.

For more information about bound databases, refer to Bound Database versus 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.

This property is read-only and shows whether V2 metadata was set when the database was created. “Long metadata” is another term for V2 metadata.

Relational Constraints displays a matrix that lists the relational constraints in effect for the database. See Interactions Between Btrieve and Relational Constraints.

Security contains property settings (tabbed areas) for Database Security and Btrieve Security. See PSQL Security for a complete discussion of security.

The following dialog in PCC is used to create a new database. The accompanying table describes the GUI objects. (See also To create a new database.)

Click an item in the image for information about its use.

The following tasks pertain to databases.

For information on named databases, see PSQL Database Concepts in Advanced Operations Guide.

You cannot delete the database to which you are currently logged in. See To log out from a database engine.

If database security is set to Mixed or Database, you must first remove the security, or it cannot be deleted. See To turn off security using PSQL Explorer and To turn off security using SQL.

If when you delete a database you also want to remove its DSN, then in Window > Preferences > PSQL > General, the option Always remove associated DSN entries must be selected.

Using the tables (data files) from one database for a newly created database with a different name can result in the inability to open the tables for the new database. In certain situations, the tables can have the original database name bound to them. For example, if the original database is set to Bound or if referential integrity is being enforced, the data files are bound to that database name. See also Bound Database versus Integrity Enforced.

To ensure that such tables can be opened for the new database, you need to repair the database name for the new database. The tables are then associated with the new database.

Tables are the objects in which databases store data. PSQL contains two types of tables: data and system. Data tables are created by users. When you create a table, it is empty until you populate it with data. System tables are created and populated as needed by the PSQL database.

See Table Editor for a detailed discussion of data tables. That topic also describes the tasks for creating and deleting tables, and working with columns, foreign keys, and so forth.

System tables appear in the PSQL Explorer under the System Objects node. You may check their contents as explained in To view properties of a table.

Table properties provides information about the table. Separate tabs let you view general properties, columns information, and indexes information. The following table describes the parameters listed on the General tab.

Schemas are metadata, or data about data. When you use PSQL as a Btrieve transactional database, no explicit schemas are needed, although a small amount of metadata is stored in the Btrieve files themselves and also within the MicroKernel Engine as it runs. But in a PSQL relational database, schemas contain all of the information used to store and manage data. This relational information is stored in data dictionary files (DDFs). Proper functioning and high performance of the SQL engine depends on valid and accurate DDFs. The information in this topic can help you to identify invalid or incomplete DDFs and determine what you can do to correct them.

DDFs define the structure of tables and their fields, as well as other features:

You can export a schema to a file for reuse or safekeeping. In PCC, right-clicking a database and selecting Export Schema opens the Export Database Schema wizard. Right-clicking a table and selecting Export Table Schema opens a dialog. In either case, you then create an exported schema file, called a SQL script, with the file extension .sql. The default export location is C:\Users\login, based on your user account.

The exported SQL script can be used in the following ways:

The rest of this section covers the following topics:

The Export Database Schema wizard offers the following settings when you export PSQL metadata:

The Export Table Schema dialog offers the following options to export table metadata:

The following example shows the use of the IN DICTIONARY clause.

If you select this option, be sure to copy any data files to the new database location before running the script file there. The data files must be present for table creation to succeed. For more information, see IN DICTIONARY in SQL Engine Reference.

The following steps show how to export and import database schemas in PCC:

If you have copied data files for use with a schema, you must place the files in their new location before importing the schema. Also, you must have exported the schema with the IN DICTIONARY option.

If you have copied the data file for the table, you must place it in its new location before importing its schema. Also, you must have exported the schema with the IN DICTIONARY option.

This topic covers some common ways to use database schemas:

You can import a database schema to create a complete copy of the database from which it was exported. The copy can be used for testing purposes or to generate metadata at run time as part of application deployment.

In scenarios such as technical support where confidentiality prevents sharing of data files, you can skip copying data files so that importing the schema creates the DDFs but with empty files.

Migrating a database from v1 to v2 format allows your application and environment to take advantage of v2 metadata features, such as longer identifier names, execution permissions for views and stored procedures, and a higher limit on the maximum number of database objects.

The steps for migrating a database from v1 to v2 format are the same as for copying a database, except that when you create the new database, you must select the Long metadata option.

When you migrate from v1 to v2 format, it is important to use the validation step to compare the v2 database against its v1 source. If validation succeeds, this confirms that you can expect the same behavior in the new database as in the old.

Many customers have PSQL databases that have been around for a long time – 20 or even 30 years. The schema may have been created with legacy tools, using third-party utilities or even handwritten. Some of these databases have invalid table definitions or have definitions that do not match their data files. The export and import process can reveal these faulty definitions so that you can correct them and enable the best function and performance of your PSQL engine.

The export action requires a user account in a group that has the CREATE database permission. Before you export the schema, log in under such an account or expect when prompted to enter the user name and password for such an account.

PSQL allows multiple table definitions for a single data file. For example, one definition might specify the first column as ID CHAR(12), corresponding to the first key in the data file. Another table definition manages the 12-character ID as a set of smaller columns, such as a SequenceNum CHAR(8), Location CHAR(2), and Zone CHAR(2). PSQL allows multiple table definitions with USING clauses referencing the same data file so long as the definitions are compatible as shown in this example.

PSQL also supports the storing of varying record layouts in the same data file by adding a column to indicate the record type for each entry. Such files are referred to as having variant records, as shown in the following example:

Tables Vendor and Customer both reference company.dat, and the first two columns of their definitions match, but after that the column definitions vary. Their two record layouts must have the same total length and also match the record length in their data file. If needed, a table definition can add extra fields to pad to the full length. Also, while some index definitions may be common to all variant records, other indexes may be used by only one table definition. In this example, applications that access company.dat must submit the correct RecType value to specify the table definition for each record.

The Export Schema feature checks data files for the number of table definitions. If it finds more than one, it exports the schema with CREATE TABLE statements followed by pairs of almost identical CREATE INDEX statements, differing only in that one includes IN DICTIONARY and the other does not.

When these extra CREATE INDEX statements are used to import the schema, they ensure proper creation of both shared and unique indexes for each table. When importing, you can expect certain types of messages to be logged. These messages are marked as errors or warnings, but they usually can be ignored. The following example explains why by continuing with the example data file company.dat shared by the tables Vendor and Customer. When the schema for these tables is imported into a new database, the following things occur:

If you know that you are working with variant tables sharing a data file, you can ignore these import log entries. You can formally confirm correct creation of the tables if the validation section of the schema import log lists no additional errors or warnings.

Exporting and importing a database schema can help identify problems in metadata definitions that can lead to unexpected or incorrect results in SQL applications. These problems often result from DDFs that are not compliant with standard SQL. Using the warning and error messages logged when exporting, importing, and validating a schema, you can evaluate and correct these schema definitions.

The troubleshooting process may take several steps, including reviewing and analyzing any or all of the following:

The following topics provide details and give examples of notable log entries, along with actions to take:

When you export a schema, PSQL attempts to generate a SQL statement for every object defined in the database. Problematic objects can produce insightful messages and warnings about possible issues to investigate. Messages generated during export are written to the Export Database Schema window. After exporting, these messages are also written to the file schema_export.log along with additional details, including the SQL statement associated with the warning. Warning messages for a particular table or column are also included in the schema.sql script, marked as comments in the format "/* <message> */".

Issue: If any table column includes a COLLATE attribute, schema export returns the following warning:

[WARN] One or more tables use the collation sequence 'UPPER.ALT'. This file must be copied to the import database location before importing.

One of these messages is entered for each unique collating sequence in the database.

Action: Make sure that each collation file exists in the new database location before importing the schema.

Issue: If schema export detects invalid size or decimal values, it returns messages like the following:

[WARN] Column <table>.<column> has an incorrect size of 0

The first message is informative and requires no further action. The second message indicates that the specified table will fail to be created when the schema is imported.

Action: To fix table definitions in the original database with an invalid size, use an ALTER TABLE statement to either correct the column size or remove the column. Then export the schema again to generate a correct CREATE TABLE statement. Alternatively, if you do not want to change the original DDFs, you can edit the schema.sql file produced by exporting to specify the correct column size. If you choose the latter, the new table created by importing the schema will not match the original and will generate validation errors.

Issue: If a table definition has multiple columns with the same offset, and at least one of the columns is not of type BIT, schema export returns a message like the following:

[WARN] Column <table>.<column> has the same offset as another column that is not type BIT

A SQL table cannot have multiple columns located at the same offset in a single table unless they are all of type BIT. If a portion of the data needs to be defined in different ways for different types of queries, you can create multiple table definitions or use views.

Action: Determine the correct columns for the offset and remove the additional columns using an ALTER TABLE statement. Alternatively, if you do not want to change your original DDFs, you can edit the schema.sql file produced by exporting to remove the extra overlapping columns. If you do not correct this, the new table created by importing the schema will have all of the columns created with unique offsets, which will produce validation errors.

Issue: Legacy DDFs may have indexes flagged to indicate that they correspond to a Btrieve null key in the data file. The PSQL engine treats this flag as a legacy null and no longer uses or maintains it. Schema export generates a message like the following:

[WARN] Btrieve NULL key flag not supported in SQL index <name> on table <name>

Action: This is an informative message, and no further action is required. For more information about legacy nulls and the newer true nulls, see Null Value in Advanced Operations Guide.

Messages generated during import are written to the Import Database Schema window. After importing, these messages are also written to the file schema_import.log along with additional details, including the SQL statement associated with the warning.

The following topics provide details and give examples of notable log entries, along with actions to take:

Issue: When you import a schema.sql script, invalid SQL statements may return errors. These can indicate the following problems in database objects specified in the DDFs of the original database:

Some of these errors result from invalid entries in the source database, such as invalid data types or column lengths, data file paths that are not relative, and so forth. Other errors can result from a previous error. For example, if a CREATE TABLE fails, subsequent CREATE INDEX statements also fail.

Action: Review the message and details from the import log file to determine the cause of the error. It may be necessary to review the schema.sql file for the complete set of SQL statements associated with the error. For example, an error generated by a CREATE PROCEDURE is logged with only the first line of the procedure, but schema.sql contains the entire statement.

Issue: The following messages usually indicate that you have variant record definitions in your database:

[WARN] [LNA][PSQL][SQL Engine] The data file '<file.ext>' in the USING clause already exists and is now associated with table '<table>'.

[ERROR] [LNA][PSQL][SQL Engine] Duplicate index exists.

Action: See also Special Case: Working with Multiple or Variant Record Definitions for additional information about these messages.

Issue: The following messages usually indicate that you have referential integrity constraints in your database:

[ERROR] [LNA][PSQL][SQL Engine][Data Record Manager] The MicroKernel cannot find the specified file (Btrieve Error 12).

[LNA][PSQL][SQL Engine][Data Record Manager]The RI definition is out of sync (Btrieve Error 73).

Typically, these errors occur when schema export creates foreign key constraints because you selected the Include IN DICTIONARY option. In the case of status 12, the data files do not exist. In the case of status 73, the data files have been copied from a database with different names.

Action: For databases with referential integrity, you must redo the schema export without selecting the Include IN DICTIONARY option, and then import the schema again. Doing so allows the schema import to create the data files and store referential integrity constraint information in them.

Issue: The following messages usually indicate that you have exported the schema from a v2 metadata database and are trying to import it into a v1 metadata database:

[LNA][PSQL][SQL Engine][Data Record Manager]This feature is not supported for the current Metadata version.

These errors occur only if your source database uses features specific to v2 metadata, such as long metadata object names, EXECUTE AS in views or stored procedures, and GRANT statements for views or stored procedures. If you export a schema from a v2 metadata database that uses no v2 metadata features, then importing it into a v1 metadata database should return no errors.

Action: If the original database uses v2 metadata, make sure the target database is also created using v2 metadata so that all v2 metadata features can be recreated.

Messages generated during validation are written to the Import Validation window. After validation, these messages are also written to the file schema_import.log, appearing after the import messages.

The validation process runs a series of queries to compare the new database to the original database. It checks for missing, extra, and mismatched entries for each of the following:

For missing objects, read the import section of the log to find the entry associated with the failed attempt to create it. This entry provides both the SQL statement and the error generated to help determine what caused the failure.

The following topics provide details and give examples of notable log entries, along with actions to take:

Issue: If you have table definitions with overlapping columns in the original database (see Export Schema Log), the corresponding table in the new database will have all columns created sequentially. This difference returns in offset mismatch errors for that table.

Action: Correct the table definition in the original database or edit the exported schema.sql file to remove the overlapping columns from the table.

Issue: Legacy databases do not support the unsigned integer data type. Some table columns that were defined as unsigned 1-byte integers were created with a data type of 1 and a bit set in the columns flags. When unsigned integer support was added, these columns could properly be defined with a data type of 14. The validation may detect this data type difference.

Action: No action is necessary. The new column definitions with data type 14 will function exactly the same as the legacy definition.

Issue: If you have a column defined in the original database with both case-insensitivity and an alternate collating sequence, it will be recreated in the new database with only the case-insensitivity flag. A column cannot have both of these attributes. Validation detects the missing COLLATE attribute for these columns.

Action: Check the table properties in the original database to confirm that both CASE and COLLATE are set in the column definition. If so, no action is necessary. The new column definition with case-insensitivity will function exactly as the original definition.

Issue: An index may fail to be created for several reasons. If your data file location contains a complete path instead of a relative path, and you select the IN DICTIONARY option, importing the schema may fail to create indexes. Also, variant record definitions may result in mismatch of indexes common to multiple table definitions for the same data file.

Action: Read the import log to find the error associated with the CREATE INDEX statement. Make necessary corrections to the source database or the schema.sql file and import the database again.

The tables that you create with PCC are initially empty. You can add data to them through PCC or by importing data. PCC provides a wizard to export data and one to import data.

See To add rows of data to the Grid.

See bdu.

The Import Data Wizard reads delimited data from a text file and adds the data to a table. The wizard allows you to select the following:

The data must use a field delimiter of the comma, colon, or tab character. A combination of carriage return and line feed must delimit records.

The Export Data Wizard exports data from a table to a text file. A combination of carriage return and line feed delimits records.

The wizard lets you specify the following:

statement.

PCC helps you to manage CREATE scripts for stored procedures, triggers, user-defined functions, and views. In PSQL Explorer these items appear in folders under each database.

Use of these features is optional but may be of interest to advanced database users.

Security is a database property that requires a user to provide a user name and password to access the database. By default, database security is turned off.

Database security can be turned on in PCC or by executing a SQL statement. Once enabled, you may create groups and users and assign permissions to them. Permissions can specify rights at three levels: database, table, and column.

When you turn security on or off, the Master user must have only one connection open and must be the only user connected at that moment. As soon as you turn security on for the first time, only the Master user can access the database. The Master user password is case sensitive, like all PSQL passwords.

For more information about security models, see PSQL Security in Advanced Operations Guide.

This section gives the steps for various PSQL security management tasks. The tasks are divided into categories in the following table.

If the database resides on a remote machine, you must provide a user name and password of an administrator or of a member of the Pervasive_Admin group for the remote machine. The user name and password are not required if the database resides on the local machine to which you are logged in (and the local machine is not running Terminal Services).

Turning on security prevents all users from accessing the database unless they log in to it using a valid database user name and password. User names and passwords cannot be set up until security is turned on, so the database will be inaccessible to each user for the period of time until you have set up a user account for that user.

You must be logged into the computer as an administrator or as a member of the Pervasive_Admin operating system security group.

Turning on security prevents all users from accessing the database unless they log in to it using a valid database user name and password. User names and passwords cannot be set up until security is turned on, so the database will be inaccessible to each user for the period of time until you have set up a user account for that user.

You must be logged into the computer as an administrator or as a member of the Pervasive_Admin operating system security group.

For information about these security policies, see PSQL Security in Advanced Operations Guide.

Note that you cannot add a group to another group.

These steps apply only to the use of the local database security model. In the Windows domain security model, network domain accounts are used for logging in to a PSQL database. Group membership is assigned by a network administrator, and PSQL queries the Windows network authentication server to verify user credentials and retrieve and match membership in PSQL groups where permissions are defined.

A user can be a member of only one group. All users in that group have the same permissions defined for that group. Once a user joins a group, any of his or her individual user permissions are ignored and all permissions are a combination of the user’s group and PUBLIC permissions. You cannot grant or revoke individual permissions for a user who is in a group.

Note that a group can be deleted only if no users are assigned to it.

As a general note for all of the tasks described here, if you wish to assign permissions to an object where the underlying Btrieve file has an owner name, then you must specify that owner name first either by using a GRANT or SET OWNER statement. For more information, see SQL Engine Reference.

For most users, the configuration of a PSQL server or its client set by default during installation can satisfy ordinary needs. However, for certain purposes, such as debugging, memory usage, or performance tuning, you may need to change the configuration settings. In PSQL these settings are called properties. You can manage them in PCC or from the command line.

The following topics in Advanced Operations Guide tell where to find the engine and client properties.

For more information on configuring servers and clients, see the following topics in Advanced Operations Guide:

By default, PCC uses its own dialogs for File Open and File Save (and File Save As). The two dialogs are titled Open SQL Document and Save SQL Document, respectively, because the files that PCC deals with are SQL documents. Accordingly, File > New creates a SQL document.

The dialogs allow you to work with files containing character encodings different from the system encoding more easily than with the standard dialogs for open and save. For example, if you create a SQL script that contains wide character data, saving the file without the proper encoding could result in lost data. For example, the system code page in use may not support wide character data.

This section covers the following topics:

The dialogs allow you to change the file encoding during the open or save action. In addition, the File Open dialog shows a preview of the data based on the selected file encoding. The following table explains the encoding choices.

In addition to changing the file encoding during the open or save action, you can set the default encoding to use for opens and saves. This same default is used for importing and exporting data and exporting schemas. See Importing Data with Import Data Wizard, Exporting Data with Export Data Wizard, and Managing Schemas. You cannot set different defaults for the open and save actions, for example.

The alternate dialogs check for valid characters in a file name before allowing the open or save action. The following set of characters are invalid and cannot be used: / : * ? \ " < > |

To allow a file to be moved between Windows and Linux or macOS, the set of invalid characters is the same for all operating systems supported by PSQL.

The Document field defaults to the directory of the last file opened or saved. You can use the Browse button to select other files and locations.

A full path and file name is required to save a SQL document. You can access the standard operating system file dialog by clicking Browse.

If you prefer, you can use the standard operating system dialogs for File Open and File Save. For example, you may have no need to work with encodings outside the system code page, in which case you may want to use the standard dialogs.

Import Data, Export Data, and Export Schema now allow you to work with files containing wide character data. You can change the file encoding during the import or export action, similar to File Open and File Save. See Encoding Choices.

The dialog field in which you specify a file path and name defaults to the path location used for the previous data import or export or schema export. (Import Data, Export Data, and Export Schema use the same persistence setting). A full path name is required to enable the import and export actions.

See also Dialogs for File Open and File Save.

Import Data allows you to change file encoding and to set a default encoding. In addition, the Preview inset shows a preview of the data based on the file name, file encoding and the options selected. For example, the following illustration shows the class.sdf table provided with PSQL about to be imported. Encoding is set to windows-1252 and Preview shows what the file data looks like based on that encoding with a COMMA delimiter and no column names in the first row.

If you import a file with a BOM, the BOM is recognized and stripped off during the import. In addition, the file is imported with the encoding specified by the BOM regardless of what encoding you specify on the dialog. That is, a file BOM overrides the Encoding selection.

Note that you can access the standard operating system dialog for file selection by clicking Browse.

See also Importing Data with Import Data Wizard.

Export Data allows you to change file encoding and to set a default encoding. Note that the Example field does not provide a preview but rather a sample given the selected options.

For example, in the following illustration, the dialog is set to export the data for the Course table provided with the Demodata sample database. The option Write column names in first row is selected and that Delimiter is set to COLON.

Note that the export action trims trailing spaces from the values of the CHAR and NCHAR data types. You can access the standard operating system dialog for file selection by clicking Browse.

See also Exporting Data with Export Data Wizard.

Export table Schema now allows you to change file encoding and to change the default encoding. Note that the Example field does not provide a preview but rather a sample given the selected options.

For example, in the following illustration, the dialog is set to export the schema for the Faculty table provided with the Demodata sample database. Note that the option add ‘IN DICTIONARY’ clause to CREATE statements is selected and that the Example inset contains an IN DICTIONARY clause.

The Export Database Schema wizard has similar settings but no Example field, since all tables are to be exported. For more information, see Managing Schemas.