以下のセクションでは、PSQL データベースの基本的な操作方法について説明します。

以下のトピックでは、PSQL エンジンの停止と起動について説明します。エンジンの特定の設定を変更した場合には、変更を有効にするためにエンジンを停止して再起動する必要があります。お使いのエンジンおよびプラットフォームの手順を選んでください。

Windows サーバー環境では、PSQL Server はサービスとして起動します。サービスはインストール処理の一部として読み込まれ、デフォルトのインストールであれば常に使用可能な状態に設定されます。

その他の PSQL 製品である DataExchange もサービスをインストールします。DataExchange は、PSQL トランザクショナル エンジンおよび PSQL リレーショナル エンジンの両方のサービスに依存します。

データベース エンジン サービスの開始、停止、再開によって依存サービスがどのように動作するかを次の表にまとめます。どのアプリケーション（PCC、Windows サービス、Net Start、PSC）を使用していたとしても、依存サービスの動作は同じです。

DataExchange のサービスを開始した場合、必須のサービスとして PSQL リレーショナル エンジンが開始します。

依存サービスは、停止することを知らせるメッセージを表示することなく停止します。

この手順は、ワークグループ エンジンがアプリケーションとしてインストールされていることを前提としています。詳細については、『Getting Started with PSQL』の PSQL Workgroup（Windows 版）のインストールを参照してください。

この手順は、ワークグループ エンジンがアプリケーションとしてインストールされていることを前提としています。詳細については、『Getting Started with PSQL』の PSQL Workgroup（Windows 版）のインストールを参照してください。

以下の条件下でエンジンを停止しようとすると、警告メッセージが表示されます。

この手順は、ワークグループ エンジンがサービス（インストール時のデフォルト）としてインストールされていることを前提としています。詳細については、『Getting Started with PSQL』の PSQL Workgroup（Windows 版）のインストールを参照してください。

この手順は、ワークグループ エンジンがサービス（インストール時のデフォルト）としてインストールされていることを前提としています。詳細については、『Getting Started with PSQL』の PSQL Workgroup（Windows 版）のインストールを参照してください。

Linux、OS X および Raspbian 上では、データベース エンジンはデーモンとして起動します。デーモンはインストール処理の一部として読み込まれ、完全インストールであれば常に使用可能な状態に設定されます。

PSQL デーモン プロセスを起動および停止するには、root ユーザーとしてログインする必要があります。次に、シェル スクリプト psql を使用した例を示します。

システムの種類に応じて、コマンド ラインで以下のように入力します。

/etc/init.d/psql start

/usr/local/psql/etc/init.d/psql start

PSQL 64 ビット サーバーでは、このコマンドはトランザクショナル エンジンとリレーショナル エンジンの両方を起動します。

システムの種類に応じて、コマンド ラインで以下のように入力します。

/etc/init.d/psql stop

/usr/local/psql/etc/init.d/psql stop

PSQL 64 ビット サーバーでは、このコマンドはトランザクショナル エンジンとリレーショナル エンジンの両方を停止します。

データベース エンジンが正しく起動または停止されなかった場合は、start および stop コマンドを使用してエンジンを強制停止する必要があります。force stop は共有メモリと PSQL が作成したセマフォを削除し、リレーショナルおよびトランザクショナル プロセスを停止します。

システムの種類に応じて、コマンド ラインで以下のように入力します。

/etc/init.d/psql force

/usr/local/psql/etc/init.d/psql force

Windows サーバー環境の場合、PSQL Server はサービスとして実行します。このサービスはデフォルト設定を使用するインストールの処理中に読み込まれ、常に使用可能な状態に設定されます。インストール後、PowerShell の Get-Service コマンドを別のコンピューターからリモートで使用して、データベース エンジンが実行されていることを確認できます。信頼関係接続を確立したら、リモート セッションを開き、PowerShell コマンド プロンプトで次のように入力します。

Get-Service -DisplayName "Actian PSQL*"

エンジンが実行中の場合、このコマンドによって次の情報が返されます。

Status   Name               DisplayName
------   ----               -----------
Running  Pervasive.SQL (... Actian PSQL Relational Engine
Running  Pervasive.SQL (... Actian PSQL Transactional Engine

リレーショナル エンジンまたはトランザクショナル エンジンが停止している場合、以下のコマンドを記載されている順序どおりに実行することで、エンジンを手動で起動することができます。

Start-Service -DisplayName "Actian PSQL Transactional Engine"
Start-Service -DisplayName "Actian PSQL Relational Engine"

エンジン サービスは、オペレーティング システムの起動と共に自動的に開始します。サービスを停止する必要がある場合は、次のコマンドを使用します。

Stop-Service -DisplayName "Actian PSQL*"

このコマンドの実行後、Get-Service コマンドを実行すると、次のような情報が返されます。

Status   Name               DisplayName
------   ----               -----------
Stopped  Pervasive.SQL (... Actian PSQL Relational Engine
Stopped  Pervasive.SQL (... Actian PSQL Transactional Engine

このセクションでは、まず、オペレーティング システム上での管理者レベルのアクセス権を必要とする PSQL のタスクと、それを必要としないタスクについての概要を説明します。次に、サポートされる各オペレーティング システムでユーザー管理者レベルのアクセス権を許可する手順を説明します。

以下のタスクを行うには、管理者レベルの権限が必要です。

管理者レベルのアクセスを行うには、次の条件を満たす必要があります。

Table Editor を使用してテーブル設計を変更するには、Pervasive_Adminグループのメンバーであっても、データベース エンジンが実行中のマシンでの完全な管理者権限を持っている必要があります。

Pervasive_Admin オプションを使用すれば、ユーザーにデータベース エンジンが存在するオペレーティング システムの管理者権限を与えることなく、そのデータベース エンジンの管理者権限を許可することができます。

Active Directory 環境内では、1 つまたは複数の Pervasive_Admin グループを使用することができます。『Getting Started with PSQL』の Active Directory サービスを参照してください。

管理者レベル権限を持たないユーザーは、実行時のみのアクセス権により以下のような操作を行うことができます。

ユーザーに管理者権限を許可するには、お使いのプラットフォームの手順に従ってください。

Pervasive_Admin のメンバーまたは Administrators のメンバーであるユーザーは、データベース エンジン上で管理者用のタスクを実行することができます。

PSQL サービスのためのオペレーティング システムの設定には、データベース エンジンを実行するマシンへのログインに影響するものがあります。これらの設定は、Pervasive_Admin グループを使用してもしなくても適用されます。

設定は PSQL Server のエンジンに適用されます。ワークグループ のエンジンをサービスとして実行している場合にはワークグループのエンジンにも適用されます。アプリケーションとして実行しているワークグループ エンジンをサービスとして実行するように切り替えたい場合は、『Getting Started with PSQL』のサービスとしてのワークグループ エンジンの起動を参照してください。

デフォルトのインストールでは、トランザクショナル サービスおよびリレーショナル サービスは共に［ローカル システム アカウント］としてログオンするよう設定されます。

［ログオン］設定を［アカウント］へ変更した場合、そのアカウントのユーザー権利ポリシーを［オペレーティング システムの一部として機能］に変更する必要があります。そうしないと、リモート ログインは失敗します。

たとえば、Monitor ユーティリティは、データベース エンジン実行中のマシン上のオペレーティング システムにログインしていることを必要とします。［アカウント］に指定したアカウントがオペレーティング システムの一部として機能しない場合、ログイン失敗のメッセージを受け取ります。

Administrator アカウントであっても、ユーザー権利ポリシーを［オペレーティング システムの一部として機能］に設定する必要があるので注意してください。

サービス プロパティで［アカウント］を指定します。

次のタスクは、ユーザー権利ポリシーの変更方法を説明します。

管理者権限を持つデータベース ユーザーとして設定されていないユーザーは、サーバー エンジンをリモートで管理することはできません。サーバーのコマンド ラインで btadmin ユーティリティを使ってこのタスクを実行することができます。

管理者権限の環境設定についての詳細は、『Getting Started with PSQL』の Linux、OS X、Raspbian での PSQL のアカウント管理を参照してください。

このセクションでは、データベースへの ODBC アクセスの設定に関する概念情報を提供します。

ここで説明するトピックには、以下の基本概念が含まれています。

PSQL は Microsoft 標準の ODBC データベース接続に対応しています。この標準に従って、ODBC を使用するアプリケーションはオペレーティング システムで定義されているデータ ソース名（DSN）を介してデータベースにアクセスする必要があります。

ODBC アプリケーションを使用してアクセスする PSQL データベースはどれも、そのデータベースを識別する DSN を持っている必要があります。PSQL データベース エンジンを指す DSN を、エンジン DSN と言います。エンジン DSN は 32 ビットのみなので、その使用は現在推奨されていません。エンジン DSN または名前付きデータベースを指す 32 ビット DSN を、クライアント DSN と言います。64 ビット オペレーティング システムの DSN は、「エンジン」や「クライアント」の呼称を付けないで、単に 64 ビット DSN と呼ばれます。

新規または修正を施す 32 ビット アプリケーションは、ローカルでもリモートでも、エンジン DSN を使用するのではなく名前付きデータベースに接続する必要があります。この代わりに、PSQL ODBC ドライバー名を指定することによって、アプリケーションが DSN レス接続を使用するという方法もあります（『ODBC Guide』の PSQL ODBC ドライバー名を参照してください）。エンジン DSN の使用を避けることで、将来エンジン DSN が PSQL でサポートされなくなってもアプリケーションを維持することができます。

Windows 64 ビット オペレーティング システムには、ODBC アドミニストレーター用の実行可能ファイルが 2 種類含まれています。1 つは 32 ビット DSN 用で、もう 1 つは 64 ビット DSN 用です。各 ODBC アドミニストレーターは、自身のビット数に合致するシステム DSN のみを列挙します。64 ビット PSQL Server または Workgroup の場合、PCC の［ツール］メニューには、32 ビットまたは 64 ビットの ODBC アドミニストレーターを起動するためのオプションが個別にあります。ODBC アドミニストレーターが既に開かれている場合、Windows ではそれをデフォルトとします。つまり、32 ビット ODBC アドミニストレーターが開いているときに 64 ビット用を起動しようとすると、Windows は 32 ビット バージョンを表示します（逆も同様）。これは PSQL の制限ではなく、Windows オペレーティング システムの制限です。

図 2 は、DSN 設定の例です。

PSQL サーバーはクライアントにもなります。PSQL のクライアント コンポーネントは、サーバー エンジンまたはワークグループ エンジンでそれぞれインストールされます。このため、サーバー コンピューターからほかのサーバーにクライアントとして接続することができます。PSQL クライアントは、PSQL サーバー エンジンがインストールされたリモート コンピューターに接続することができます。

ODBC クライアント サーバー アーキテクチャは特定のデータ セットをそれぞれの名前で呼び出すので、わかりやすい名前で参照することができます。DSN の作成には一般的に 3 種類の方法があります。

PSQL が使用するデータベースが内部データベース名（DBNAME）であることを識別する方法です。データベース アクセスに ODBC を使用している場合、1 つの DBNAME を参照する DSN（データ ソース名）エントリを作成する必要があります。同じ DBNAME を参照する複数の DSN を設定することもできます。サーバー上のデータ ファイルの物理的な場所が変更された場合、DBNAME のみを更新する必要があります。すべての DSN は変更されません。

MicroKernel エンジンのみからアクセスされる PSQL データベースでは DSN は必要ありません。しかし、そのデータベース テーブルは PCC で表示されず、PCC を使用して操作することもできません。PCC でテーブルのデータを可読形式で表示するには、テーブルがデータ辞書ファイル（DDF）に定義されている必要があります。『DDF Builder User's Guide』を参照してください。

PSQL Java ユーティリティで作成したデータベースも DSN を必要としません。たとえば、PSQL Control Center は ODBC ではなく JDBC を使用します。

データベースが存在するサーバーの名前を知っておく必要があります。データベースが既に DBNAME を持っている場合、PCC はこれを使用します。新しいデータベースを作成するが既存のデータ ファイルを使用したい場合は、サーバー上のデータ ファイルの場所を知っておく必要があります。

リモート マシン上に DSN を作成するには、アクセスするデータベースのあるリモート マシンで管理者権限を持っている必要があります。ローカル マシン上でシステム DSN を作成する、OS のシステム権限を持っている必要があります。

ODBC インターフェイス GUI は、Windows オペレーティング システムが 32 ビットか 64 ビットかによって異なるので注意してください。32 ビット DSN 用を使用すれば、エンジン DSN を指定することができます。64 ビット インターフェイス ドライバーは名前付きデータベースのみをサポートします。64 ビット クライアント インターフェイスはローカルの名前付きデータベースに接続できる（エンジン DSN の機能に置き換わる）、あるいはリモートの名前付きデータベースに接続できます。エンジン DSN への接続はサポートされていません。

Linux および OS X では、サーバーで dbmaint ユーティリティを使用してデータベース名を作成します。dbmaint の詳細については、dbmaint または dbmaint man page を参照してください。

dsnadd ユーティリティを使用します。dsnadd を参照してください。

PCC を使用して PSQL エンジンにアクセスし、リモート システムにあるデータにアクセスすることができます。このリモート システムはネットワーク上でアクセス可能なすべての PSQL Server です。この方法は、特に Windows Nano Server や IoT Core 環境で実行するエンジンにアクセスする際に役立ちます。

ここでは、PCC を使用してリモート エンジン上のデータを表示したり操作したりする例を示します。

これで、リモート データベース エンジンからデータを取得しました。

データベース操作を含む高度な操作やメンテナンス方法については、『Advanced Operations Guide』を参照してください。

このセクションでは、Microsoft Access および Microsoft Excel を使用してデータにアクセスする方法を説明します。

このセクションでは、以下の例について説明します。

このトピックの手順では、データ辞書ファイル（DDF）またはデータ ファイルを削除しません。

デフォルトでは、PSQL Control Center でデータベースを削除した場合、関連する DSN エントリも同時に削除されます。