PSQL Control Center の使用
 
このページをシェアする                  
PSQL Control Center の使用
PSQL Control Center の概要
PSQL Control Center(PCC)はデータベースの作成および管理や、データベース エンジンの制御を行うためのグラフィカル ツールです。ここから本製品のほとんどすべての機能にアクセスすることができます。この章では、PCC のインターフェイスおよび一般的な操作について説明します。
PSQL Control Center の概要
Windows サーバー上のサービス
データベース エンジン
Capacity Usage ビューアー
Monitor
Defragmenter
データベース
[データベースの新規作成]GUI のリファレンス
PSQL データベースの作成、編集、削除、および修復
テーブル
スキーマの管理
データの作成、インポート、およびエクスポート
ストアド プロシージャ、トリガー、ユーザー定義関数、およびビュー
グループ、ユーザー、およびセキュリティ
データベース エンジンとクライアントの設定
[ファイルを開く]ダイアログと[ファイルを保存]ダイアログ
データのインポート/エクスポート、スキーマのエクスポートでサポートされるワイド文字データ
PSQL Control Center の概要
PSQL Control Center(PCC)は、PSQL エンジンへの接続、データベースとテーブルの設定や変更、データのクエリや更新、エンジンのパフォーマンス調整、および PSQL ドキュメント ライブラリへのアクセスを行うための、統合されたフレームワークです。
PCC では PSQL エクスプローラーと呼ばれるオブジェクト ツリー形式のファイル エクスプローラーを使用します。このツリーは、展開すると詳細を表示します。オブジェクトには、エンジン、データベース、テーブル、ユーザー設定などがあります。次の図は、いくつかのウィンドウ ビューが表示された PCC を示します。PSQL エクスプローラーは左側のツリー ビューです。
図 13 Windows プラットフォームの PSQL Control Center
図 14 PSQL Control Center(Linux プラットフォーム)
Linux ディストリビューションに応じて、あるいは OS X を使用している場合、PCC(画面の)表示が異なる場合がありますが、機能は同一です。
PCC のインストール
Windows プラットフォームでは、PCC はデータベース エンジンまたはクライアントのインストール時にデフォルトでインストールされます。『Getting Started with PSQL』の PSQL のオプション機能を参照してください。
Linux および OS X では、PCC は完全インストールに含まれます。『Getting Started with PSQL』の Linux および OS X におけるフル インストールとクライアント インストールを参照してください。
Windows での PCC の起動
オペレーティング システムの[スタート]メニューまたはアプリ画面から Control Center にアクセスします。実行ファイルの pcc.exe を実行することもできます。
Linux での PCC の起動
コマンド プロンプトから実行スクリプト ファイルの pcc を実行して PCC を起動します。このスクリプト ファイルは、デフォルトで usr/local/psql/bin ディレクトリにインストールされます。
ファイル ブラウザー アプリケーションでスクリプト ファイルをダブルクリックするのではなく、コマンド プロンプトから PCC を起動することをお勧めします。5PCC の実行に関するトラブルシューティング ガイドを参照してください。
Linux 上で PCC を起動するには、以下の条件に合致する必要があります。
表 4 Linux で PCC を起動するための要件
要件
説明
PSQL Server または Client
同一マシンに互換性のある PSQL Server または Client がインストールされている必要があります。
X Server へのアクセス
xhost コマンドは、X Windows System へのクライアントのアクセスを制御します。デフォルトで、xhost はアクセスをオンにします。X Windows System を起動したユーザーのみが PCC を起動できます。
X Windows System クライアントの制限を解除するには、ターミナル ウィンドウで xhost + を入力します。
Java Runtime Environment(JRE)
PCC を実行するために必要な JRE コンポーネントは、PSQL の一部としてインストールされます。PCC は、PSQL の一部としてインストールされる JRE のローカル バージョンを使用します。
PCC を実行する要件に合致しているのに、実行に問題がある場合は、以下のトラブルシューティング ガイドを参考にしてください。
表 5 PCC の実行に関するトラブルシューティング ガイド
トラブルシューティングする状態
説明
"java.lang.UnsatisfiedLinkError" というエラーを受け取った。
このエラーは、ファイル ブラウザー アプリケーションを使用してスクリプト ファイルをダブルクリックして PCC を起動しようとしたときに、よく起こります。コマンド プロンプトから PCC を起動してください。
このエラーは、LD_LIBRARY_PATH 変数が設定されていない場合に発生します。PCC スクリプトがこの変数を設定します。この変数は、以下のコマンドを使用して明示的に設定することもできます。
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/psql/lib64
PCC を psql または rootユーザーとして実行しようとすると、"SWT no more handles" というエラーが返される。
PCC を実行するには、psql または root ユーザーとしてログインする必要はありません。ただし、これらのユーザーのどちらでもない場合は、pvsw グループのメンバーである必要があります。
"SWT no more handles" エラーは、X Server がクライアントへの接続を拒否したために発生します。psql または root ユーザーに切り替える前に、コンソール ウィンドウを開き、xhost + と入力してほかのクライアントが X Server に接続できるようにします。
これで、psql または root ユーザーに切り替えることができます。
また、場合によっては DISPLAY 環境変数を設定する必要があります。psql または root ユーザーとして、コンソール ウィンドウで以下のコマンドを入力します。
export DISPLAY=:0.0
または
export DISPLAY=localhost:0.0
PCC のエラー ログ ファイルを表示、またはエラーをコンソール ウィンドウにリダイレクトしたい。
デフォルトで、PCC エラーのログ ファイルはユーザーのホーム ディレクトリのサブディレクトリにあります(サブディレクトリは、dir_pcc/workspace/.metadata です)。トラブルシューティングのためには、エラーをコンソール ウィンドウにリダイレクトするとより便利です。
エラーをコンソール ウィンドウにリダイレクトするには、PCC の起動時に ‑consoleLog オプションを使用します。
pcc -consoleLog
以下のエラー メッセージが返された。"データベース エンジンに接続できません。ターゲット マシンがアクセス可能で、かつエンジンが実行されていることを確認してください。"
このエラー状況は、ローカル サーバーを管理しようとした場合に発生します。
ローカル サーバーを管理するには、pvsw グループのメンバーであるか root ユーザーである必要があります。
root 以外のユーザーとして PCC を起動しようとすると、"GTK IM Module SCIM: Cannot connect to Panel!" というエラーが返される。
いくつかの Linux OS では、環境変数 GTK_IM_MODULE を指定する必要があります。
この問題を解決するには、PCC を起動する前にコンソール ウィンドウで、以下のコマンドを入力します。
export GTK_IM_MODULE=scim-bridge
OS X での PCC の起動
OS X では、デスクトップにログインしているユーザーのみが PCC を起動することができます。Finder を開き、[Applications]>[Actian PSQL]>[PSQL Control Center]の順に開きます。
PCC キャッシュをクリアする必要がある状況
効率のため、PCC により特定の情報がキャッシュされます。キャッシュは、PCC と相互作用する製品をインストールまたはアップグレードした後でクリアする必要があります。これは、インストールまたはアップグレードによる変更内容が PSQL エクスプローラーに反映されるようにするためです。たとえば、DataExchange をインストールまたはアップグレードする場合、PCC キャッシュをクリアする必要があります。
キャッシュは、PCC をパラメーターを使ってコマンド ラインから起動した場合にのみクリアできます。
PCC のキャッシュをクリアするには
1 PCC を実行中の場合は終了します([ファイル]>[終了]を選択します)。
2 コマンド プロンプトで、PSQL インストール ディレクトリの PSQL\bin\ ディレクトリに移動します。
PSQL ファイルのデフォルトの保存場所については、『Getting Started with PSQL』の PSQL ファイルはどこにインストールされますか?を参照してください。
3 次のコマンドを入力します。
pcc -clean
これにより、PCC が起動してキャッシュがクリアされます。新しくインストールまたはアップグレードされた製品が PSQL エクスプローラーに表示されます。
メモ: PCC の通常の使用時に -clean パラメーターを使用して起動しても、何の利点もありません。このパラメーターは、プラグイン製品をインストールまたはアップグレードした場合にのみ必要になります。
PCC 内のエディターおよびビュー
PCC のメイン ウィンドウには、以下のエディターとビューが含まれます。
PSQL エクスプローラー
SQL Editor
グリッド
テキスト
アウトライン
Table Editor
さまざまなエディターおよびビューを使用してオブジェクトを表示および操作することができます。同じ種類の複数のエディター(たとえば、SQL Editor)を同時に開くことができます。編集中の各オブジェクトは、エディター上部にタブによって示されます。タブにはオブジェクトの名前が表示されます。エディターで変更したデータは、明示的に保存する必要があります(たとえば、[ファイル]>[上書き保存]を使用)。
PSQL エクスプローラーのようなビューは、一度に 1 つしか開けません。ビュー内で実行された操作は、保存していない場合でも、直ちに適用されます。
エディターおよびビューの特性
以下の表にエディターとビューの特性をまとめます。
表 6 PCC のウィンドウ ビューの特性
特性
PSQL エクスプローラー
SQL Editor
グリッド
テキスト
アウトライン
Table Editor
そのビュー固有のアイコンを含む
* 
 
* 
* 
 
 
閉じることができる
 
* 
* 
* 
* 
* 
最小化できる
 
 
* 
* 
* 
 
最大化できる
 
* 
* 
* 
* 
* 
以前のサイズに戻すことができる
 
* 
 
 
 
* 
新規ウィンドウで開くことができる
* 
* 
* 
* 
* 
 
PCC メイン ウィンドウ内で再配置できる
 
* 
* 
* 
* 
* 
PCC から取り出して、デスクトップに配置できる
 
 
* 
* 
* 
 
PSQL エクスプローラー
このビューでは、複数の種類のオブジェクトをツリー形式で表示し、さまざまな作業が行えます。
オブジェクトとそのプロパティ
右クリック タスク
オブジェクトとそのプロパティ
オブジェクトのツリーには PSQL という名前のルート ノードがあります。ルート ノードに含まれるのは、クライアント、サービス(ある場合)、データベース エンジン、データベース、テーブル、ビュー、ストアド プロシージャ、ユーザー定義関数、トリガー、グループ、ユーザー、およびシステム オブジェクト(システム テーブルなど)です。
PSQL エクスプローラー内のほとんどのオブジェクトは、展開して詳細を表示することができます。下位のオブジェクトを表示するには、オブジェクトの左にある展開アイコンをクリックします。展開アイコンは、プラス記号 "+"、三角矢印 ""、またはこれらに類似した記号です。この折りたたみアイコンは展開アイコンをクリックすると切り替わって表示されます。下位オブジェクトを非表示にするには、折りたたみアイコン("-" 記号など)をクリックします。
オブジェクトにプロパティ(設定)を適用する場合は、そのオブジェクトを右クリックして[プロパティ]を選択します。また、オブジェクトをクリックしてから Alt + Enter キーを押してプロパティを表示することもできます『Advanced Operations Guide』の設定リファレンスも参照してください。
図 15 PSQL エクスプローラーに表示されるオブジェクトの例
右クリック タスク
プロパティへのアクセス以外にも、オブジェクトの右クリックによって PSQL エクスプローラーからは多くのタスクを実行することができます。次の表ではそれらのタスクについて簡単に説明します。
表 7 PSQL エクスプローラーにおけるオブジェクトの右クリック タスク
対象
タスク
右クリック場所
詳細情報
全オブジェクト
オブジェクトの設定プロパティの表示または設定
どのオブジェクトでも可能で、[プロパティ]を選択します。
 
システム
リモート データベース エンジンで使用するサーバーの登録
(PSQL をインストールしたときに、ローカル エンジンは自動的に PCC へ登録されます)
PSQL ノード
PSQL ルート オブジェクトの下位にあるどのオブジェクトを右クリックしても、リモート エンジンを対象とする作業が可能です。
Windows マシン上の PSQL サービスを使用した作業
サービス ノード(インストールのエディションで適用される場合)
データベース エンジンのログインおよびログアウト
エンジン ノードの下位にあるデータベース エンジン
同時セッション数やデータ使用量の監視
エンジン ノードの下位にあるデータベース エンジン
特定の動作と属性の監視
エンジン ノードの下位にあるデータベース エンジン
リモート データベース エンジンの削除
エンジン ノードの下位にあるデータベース エンジン
データベース
作成
データベース ノード
このタスクは、エンジン ノードの下位にあるオブジェクトからも実行できます。
削除
データベース ノードの下位にあるデータベース
データベースのログインおよびログアウト
データベース ノードの下位にあるデータベース
テーブルを新しいデータベースに関連付ける
(元のデータベース名にバインドされたテーブルのデータベース名を修正する)
データベース ノードの下位にあるデータベース
データベース名を修復するにはを参照し、コピーしたテーブルと新しいデータベースを関連付けてください。
スキーマ、
テーブル
データベース スキーマのエクスポート
データベース ノードの下位にあるデータベース
テーブル スキーマのエクスポート
テーブル ノードの下位にあるテーブル
テーブルの追加
(SELECT * from table_name クエリを実行する)
データベース ノードの下位にあるデータベースまたは
テーブル ノードの下位にあるテーブル
テーブルを開く
テーブル ノードの下位にあるテーブル
テーブルの編集
テーブル ノードの下位にあるテーブル
テーブルのインポート
テーブル ノードの下位にあるテーブル
テーブルのエクスポート
テーブル ノードの下位にあるテーブル
テーブルの削除
テーブル ノードの下位にあるテーブル
ユーザー、
グループ
ユーザーの追加
データベース ノードの下位にあるデータベースまたは
ユーザー
グループの追加
データベース ノードの下位にあるデータベースまたは
グループ
ユーザーまたはグループの削除
ユーザーまたはグループ
トリガー、
ストアド プロシージャ
ユーザー定義関数、
ビュー
作成
データベース ノードの下位にあるデータベースまたは
トリガー、
ストアド プロシージャ、
ユーザー定義関数、
ビュー
このタスクは、エンジン ノードの下位にあるオブジェクトからも実行できます。
編集
データベース ノードの下位にあるデータベースまたは
トリガー、
ストアド プロシージャ、
ユーザー定義関数、
ビュー
このタスクは、エンジン ノードの下位にあるオブジェクトからも実行できます。
削除
データベース ノードの下位にあるデータベースまたは
トリガー、
ストアド プロシージャ、
ユーザー定義関数、
ビュー
このタスクは、エンジン ノードの下位にあるオブジェクトからも実行できます。
SQL Editor
SQL Editor を使用すると、PSQL データベースに対し、SQL(構造化問い合わせ言語)ステートメントを実行することができます。詳しい説明については、SQL Editor を参照してください。
グリッド
グリッド ウィンドウは、スプレッドシートのような行列形式で SQL ステートメントの実行結果を表示します。各フィールドは列として示され、データは列内のセルに表示されます。グリッド セル内でデータを直接変更することができるだけでなく、グリッドに行を追加することもできます。
Table Editor および SQL Editor は、共にグリッドを使用します。詳細については、Table Editor を使ってテーブル データを表示するにはおよびグリッド ウィンドウ ビューを参照してください。
テキスト
テキスト ウィンドウ ビューは、テキスト形式で SQL ステートメントの実行結果を表示します。テキストは表示のみです。テキストを変更してデータ値を変更することはできませんが、テキストをコピーすることはできます。詳しい説明については、テキスト ウィンドウ ビューを参照してください。
アウトライン
アウトライン ウィンドウを使用すると、SQL ステートメントをツリー構造で表示することができます。ツリーのルート ノードは SQL Editor ウィンドウ ビューと同じ名前です。詳しい説明については、アウトライン ウィンドウ ビューを参照してください。
エディターがアウトラインをサポートしていない場合はアウトライン ウィンドウは利用できないので注意してください。現在、SQL Editor のみがアウトライン ビューをサポートしています。
Table Editor
Table Editor を使用すると、テーブルの列の追加、削除または特性の変更を行うことができます。このテーブルは、新規作成したものか、または編集したい既存のテーブルです。詳しい説明については、Table Editor を参照してください。
ユーザー設定
PCC で全般の初期設定を行うことができます。PCC のウィンドウ ビューや外部ツールの初期設定を行うこともできます。
グリッドの初期設定を行うには
1 PCC の[ウィンドウ]メニューで、[設定]をクリックします。PSQL ノードが展開されていない場合は、展開します。
2 全般の設定]をクリックします。
全般の初期設定で指定できるオプションは、以下のとおりです。
関連付けられている DSN エントリは常に削除されます(DSN の削除を参照してください)。
SQL ドキュメントを開くたびに、新しいデータベースの入力を求めるダイアログを表示しない(SQL クエリのデータベース コンテキストを設定するにはを参照してください)。
関連付けられている DSN エントリは常に削除されます。]を選択して、データベースのすべての DSN エントリがプロンプトなしでデータベースと一緒に削除されるようにします。
SQL ドキュメントを開くたびに、新しいデータベースの入力を求めるダイアログを表示しない。]の選択を解除すると、SQL Editor で SQL ドキュメントを開くたびにデータベースの選択を求められます。このオプションが選択されていない場合は、これを選択して、SQL ドキュメントを開いたときに最近選択したデータベースを使用するようにします。選択されたデータベースは、PCC のセッションをまたいで保持されることはありません。PCC を閉じて再度開いた場合は、新しいデフォルトのデータベース コンテキストを選択する必要があります。
PCC ウィンドウ ビューの初期設定
以下の PCC ウィンドウ ビューの初期設定を行うことができます。
データ グリッド
Defragmenter
Monitor
SQL Editor
Table Editor
テキスト出力
PCC ウィンドウ ビューの初期設定を行うには
1 PCC の[ウィンドウ]メニューで[設定]をクリックし、PSQL ノードが展開されていない場合は展開します。
2 以下の操作のいずれかを実行します。
データ グリッドの初期設定を行うには、[データ グリッド]をクリックします。
Defragmenter の初期設定を行うには、[Defragmenter]をクリックします。
Monitor の初期設定を行うには、[Server Monitor]をクリックします。
SQL Editor の初期設定を行うには、[SQL Editor]をクリックします。
Table Editor の初期設定を行うには、[Table Editor]をクリックします。
テキスト出力の初期設定を行うには、[テキスト出力]をクリックします。
ファイル エンコードの初期設定
ファイル エンコードの初期設定によって、ワイド文字 データを含むファイルの作業をより簡単に行うことができるようになりました。この初期設定には以下の機能があります。
ファイルを開く/保存に PCC ダイアログを使用するためのオプション
PCC における以下の操作で使用するデフォルト エンコードを選択できるエンコード一覧
PCC ファイルを開く
PCC ファイルを保存
データのインポート
データのエクスポート
テーブル スキーマのエクスポート
ファイルを開く/保存に、PCC ダイアログを使用するように設定するには
1 PCC で、[ウィンドウ]>[設定]>[PSQL]>[ファイル エンコード]を選択します。
2 [ファイルを開く]および[ファイルを保存]時にエンコードのプロンプトを表示しない]オプションが選択されていないことを確認してください。デフォルトでは、このオプションは選択されていません。
3 OK]をクリックします。
デフォルトのエンコードを設定するには
1 PCC で、[ウィンドウ]>[設定]>[PSQL]>[ファイル エンコード]の順に選択します。
2 デフォルト エンコード]ドロップダウン リストからエンコードを選択し、「OK」をクリックします。
 
表 8 デフォルト エンコードの選択肢一覧
エンコード
説明
(システム コード ページ)
デフォルトは、現在使用しているシステム コード ページです。たとえば、Windows の英語版プラットフォームの場合は、一般的に "Windows-1252" が設定されています。
Big5
Big5 は繁体字中国語の文字エンコードで、中国語の中でもっとも一般的に使われています。
EUC_JP
EUC(Extended Unix Code)_JP は可変幅の文字エンコードで、日本語文字の 3 つの標準セットである IS X 0208(基本漢字)、JIS X 0212(補助漢字)、そして JIS X 0201(半角カナ)の要素を表すのに使用します。
Shift_JIS
Shift_JIS(Japan Industrial Standards)は日本語の文字エンコードです。
UTF-8
UTF(Universal Character Set Transformation Format)-8 は 8 ビットの可変幅の文字エンコードで、Unicode 文字セットですべての文字を表すことができます。このエンコードは ASCII との下位互換性があり、エンディアンや BOM(Byte Order Mark:バイト オーダー マーク)が回避できるよう設計されています。
UTF-8 with BOM(BOM 付き UTF-8)
UTF-8 と同様ですが、こちらは BOM(バイト オーダー マーク)が付きます。この BOM は、エンディアン(バイト順)を示すのに使用する Unicode 制御文字で、ファイルを保存するときに付けられます。
UTF-16BE
16 ビットの UTF エンコードで、ビッグ エンディアン(BE)のバイト オーダーが使われます。
UTF-16BE with BOM(BOM 付き UTF-16BE)
UTF-16BE と同様ですが、こちらは BOM(バイト オーダー マーク)が付きます。BOM はファイルを保存するときに付けられます。
UTF-16LE
16 ビットの UTF エンコードで、(LE)のバイト オーダーが使われます。
UTF-16LE with BOM(BOM 付き UTF-16BE)
UTF-16LE と同様ですが、こちらは BOM(バイト オーダー マーク)が付きます。BOM はファイルを保存するときに付けられます。
メモ:デフォルトで、PCC は一度開かれたファイルのエンコード形式を記憶します。ファイルを編集し、上書き保存する場合、その編集内容は元の(記憶した)エンコードで保存されます。しかし、PCC の[別名保存]ダイアログを使用すれば、エンコードを指定して編集内容を保存することができます。
ファイルが BOM 付きの場合は、PCC が自動的にエンコード方法を検出し、PCC でファイルを選択して開くダイアログ([ファイル]メニューの[開く])にそのエンコードを表示します。BOM が付いてないファイルで、バイト オーダーが重要になる場合は、ファイルを保存するときに適切なエンコードを選択する必要があります。
メモ: ファイルのエンコードの初期設定は、ファイルを開く/保存、データのインポート/エクスポート、スキーマのエクスポートの各ダイアログからも行えます。ダイアログ内の[デフォルトのエンコードを変更する]リンクをクリックしてください。
その他のユーティリティ
一部のユーティリティは、PCC インターフェイスと完全に統合されていません。ただし、以下のユーティリティは[ツール]メニューから選択することによって PCC 内から起動することができます。
ODBC アドミニストレーター - 64 ビット オペレーティング システムの場合、32 ビットまたは 64 ビット用に別々の ODBC アドミニストレーターを選択できます(『ODBC Guide』の DSN のセットアップおよび接続文字列を参照してください)。対象ではない方の ODBC アドミニストレーターを起動しようとしても、対象とする ODBC アドミニストレーターを開きます。つまり、32 ビット ODBC アドミニストレーターが開いているときに 64 ビット用を起動しようとすると、Windows は 32 ビット バージョンを表示します(逆も同様)。言い換えると、ODBC アドミニストレーターは同時に 1 つのバージョンしか実行されないということです。これは、PSQL の制限ではなく、Windows の制限です。
DDF Builder(『DDF Builder User's Guide』の DDF Builder についてを参照)
Defragmenter(『Advanced Operations Guide』のデータ ファイルの断片化の監視を参照)
Function Executor(『Advanced Operations Guide』の Btrieve オペレーションのテストを参照)
License Administrator(ライセンス管理を参照)
Maintenance(『Advanced Operations Guide』の Maintenance を使用した Btrieve データ ファイルの操作を参照)
Monitor(『Advanced Operations Guide』の監視を参照)
PSQL System Analyzer(PSQL System Analyzer(PSA)を参照)
Query Plan Viewer(『SQL Engine Reference』の Query Plan Viewer を参照)
Rebuild(『Advanced Operations Guide』のデータ ファイルの変換を参照)
Gateway Locator(PSQL Workgroup で PCC をインストールした場合)(『Getting Started with PSQL』のゲートウェイ構成を参照)
メモ: これらのユーティリティは、Windows プラットフォームではデフォルトで[ツール]メニューに表示されます。すべてのプラットフォームで、[ツール]メニューをカスタマイズすることができます。手順については、次のセクションを参照してください。
外部ツール
PCC の[ツール]メニューに独自のソフトウェア プログラムを追加することができます。
外部ツールを追加するには
1 PCC の[ウィンドウ]メニューで、[設定]を選択します。PSQL ノードが展開されていない場合は、展開します。
2 外部ツール]をクリックします。
3 新規]をクリックします。
4 ツール]メニューに表示させたい名前を[ツールのラベル]に入力します。
5 ツールの場所]に、プログラムのパスとファイル名を入力します。
ファイルの場所を参照するには参照ボタン をクリックします。
6 また、プログラム起動時に渡すパラメーターを[ツールのパラメーター]に入力することもできます。
7 OK]をクリックします。
8 OK]をクリックして(または[適用]をクリックしてから[OK]をクリック)して[設定]ダイアログを閉じます。
外部ツールの初期設定を行うには
1 PCC の[ウィンドウ]メニューで、[設定]をクリックします。PSQL ノードが展開されていない場合は、展開します。
2 外部ツール]をクリックします。
3 外部ツール リスト内の目的のツールをクリックします。
4 以下の操作のいずれかを実行します。
リストからツールを削除するには[削除]をクリックします。
ツールをリストの上方向に移動するには、[上へ]をクリックします。
ツールをリストの下方向に移動するには、[下へ]をクリックします。
Windows サーバー上のサービス
PCC を使用すると、Windows のコントロール パネルのサービスを使用することなく、PSQL Server を Windows コンピューターで操作できます。PCC から開始、停止、および開始時の設定を行うことができます。
PSQL を完全に停止させるには、リレーショナル サービスおよびトランザクショナル サービスの両方を停止させる必要があります。どちらか 1 つのサービスを停止しただけでは、データベース エンジンを完全に停止させることはできません。
このセクションの内容は Windows プラットフォームにのみ適用されます。Linux には適用されません。
メモ: データベース エンジン以外の PSQL 製品もサービスとして実行されます。これらのほかの製品のサービスは、データベース エンジンのサービスから独立しています。詳細についてはサービスの依存関係を参照してください。
サービスを開始または停止するには
1 PSQL エクスプローラー で、サービス ノードを展開します。
2 停止または開始するサービスを右クリックします。
3 以下の操作のいずれかを実行します。
[サービスの開始]をクリックして、サービスを開始します。
[サービスの停止]をクリックして、サービスを停止しす。
[サービスの再開]をクリックして、サービスを再開します。
ヒント: また、1 つのコマンドですべてのサービスを停止または再開することができます。サービス ノードを右クリックし、[全サービスの停止]または[全サービスの再起動]をクリックします。
サービスの開始ポリシーを設定するには
1 PSQL エクスプローラー で、サービス ノードを展開します。
2 開始ポリシーを設定するサービスを右クリックします。
3 プロパティ]をクリックし、希望のポリシーを選択します。
 
開始ポリシー
説明
手動
オペレーティング システム起動後に、サービスを手動で開始する必要があります。
自動
サービスは、オペレーティング システムが起動したときに自動的に開始します。
無効
サービスは操作から除外され、オペレーティング システムの起動にも影響を受けません。
4 OK](または[適用]の次に[OK])をクリックします。
サービスのプロパティ
Advanced Operations Guide』の PCC でサービスの起動ポリシーを設定するにはを参照してください。
データベース エンジン
PCC を使用して、ローカル マシン上のデータベース エンジンまたはリモート サーバー エンジンを操作することができます。リモート サーバー エンジンで動作するには、PCC に通知する必要があります。この手順を、サーバーの「登録」と言います。
ローカル サーバーは、PSQL をインストールしたときに、自動的に PCC へ登録されます。ローカル サーバーは PSQL エクスプローラーのエンジン ノードの下の最初のエントリとして表示されます。
リモート サーバー エンジンを登録するには
1 PSQL エクスプローラーで、最上位ノード PSQL を右クリックします。
2 新規作成]>[サーバー]をクリックします。
3 登録したいサーバーを識別します。
ネットワーク上でサーバーを識別する名前、またはサーバーの IP アドレスを入力します。
4 完了]をクリックします。
サーバーは、PCC の PSQL エクスプローラー ウィンドウのエンジン ノードの下に表示されます。
データベース エンジンからログアウトするには
この手順では、サーバーからデータもデータベースも削除しません。ログアウトは、データベース エンジンとお使いのコンピューター上の PCC 間の通信を切断するだけです。
1 PSQL エクスプローラーでエンジン ノードを展開します。
2 ログアウトするサーバー エンジンを右クリックします。
3 ログアウト名前)]をクリックします。
名前は、PCC を介して現在サーバーにログインしているユーザーの名前を反映します。この名前は、特定のユーザー名とパスワードが指定されなかった場合は匿名です。
そのデータベース エンジンで展開されていたノードは折りたたまれます。
データベース エンジンに再接続するには
1 PSQL エクスプローラー で、サーバー エンジンのノードを展開します。
データベース エンジンにログインするには
1 PCC PSQL エクスプローラーでデータベース名を右クリックし、次に、ログアウト名前)をクリックします。
名前は、PCC を介して現在サーバーにログインしているユーザーの名前を反映します。デフォルトで、名前匿名です。これは、特定のユーザー名とパスワードが指定されなかったことを意味します。
そのデータベース エンジンで展開されていたノードは折りたたまれます。
2 データベース名を右クリックします。
3 ログイン]をクリックします。
4 ユーザー名およびパスワードを入力します。
これらを空白のままにして匿名でのログインを行うことができます。
5 OK]をクリックします。
リモート データベース エンジンを削除するには
マシンを使用しなくなったなどの状況によって、リモート データベース エンジンの削除が必要となることもあります。
1 PSQL エクスプローラーでエンジン ノードを展開します。
2 削除対象のリモート データベース エンジンを右クリックします。
3 削除]をクリックします。
この削除操作は確認メッセージを表示することなく直ちに実行されるので注意してください。
データベース エンジンのプロパティ
データベース エンジンとクライアントの設定を参照してください。
Capacity Usage ビューアー
PCC では、すべてのデータベース エンジンの同時セッション数とデータ使用量を監視する Capacity Usage ビューアーを提供します。このビューアーは特に、異なるライセンス モデルを使用する PSQL エンジンへの移行を検討する際に役立ちます。
Advanced Operations Guide』の Capacity Usage ビューアーを参照してください。
Monitor
PCC ではデータベース エンジンの特定の動作と属性を監視することができる Monitor ユーティリティを組み込んでいます。このユーティリティは MicroKernel エンジンおよびリレーショナル エンジンの状況も監視できます。監視情報は一連のタブ構成で表されます。タブの配置は必要に応じて変えることができます。タブ内のデータ列も配置を変えたり並べ替えたりすることができます。ある特定の時点のスナップショットを表示し、その情報は手動または自動でリフレッシュすることができます。
Advanced Operations Guide』のデータベースの状態の監視を参照してください。
Defragmenter
PCC で提供される Defragmenter ユーティリティによって、エンジンのパフォーマンスを低下させる恐れのある、データ ファイルの断片化を検出することができます。また、Defragmenter では、順序が正しくないレコードを再配置したり、データの削除によって空いた領域を取り除くことで、断片化を修正することもできます。ファイルの最適化によってそのファイルのデータが変更されることはありません。また、ファイルの最適化中でもレコードの作成、読み取り、更新または削除が可能です。ほとんどの場合、Defragmenter の機能を使用するためにダウンタイムを設ける、または業務を停止する必要はなく、データベース エンジンの実行中にもこの機能を使用することができます。
Advanced Operations Guide』のデータ ファイルの断片化の監視を参照してください。
データベース
データベースは、まとめて格納されているデータの集合です。新しく作成されたデータベースは空で、テーブルを伴っています。詳しい説明については、『Advanced Operations Guide』の PSQL データベースを参照してください。
データベースのプロパティには、ファイルの場所、参照整合性、セキュリティおよびデータベースがバインドされているかどうかなどの項目が含まれます。
メモ: サーバー エンジンにデータベースを追加する場合、そのサーバー オペレーティグ システムでの管理者権限を持っている必要があります。管理者権限を持っていない場合は、データベースの追加が許可されません。
データベース エンジンからログアウトするには
1 PSQL エクスプローラーでエンジン ノードを展開します。
2 登録されているサーバーのノードを展開し、そのサーバー上のデータベースを表示します。
3 ログアウトするデータベースを右クリックします。
4 ログアウト名前)]をクリックします。
名前は、現在データベースにログインしているユーザーの名前を反映します。データベースでセキュリティが有効にされていない場合、名前Master です。現在のユーザーが Master としてログインしている場合は、名前も Master です。
そのデータベースで展開されていたノードは折りたたまれます。
データベースのプロパティ
データベースのプロパティは、PCC 内のプロパティ ダイアログ ボックスから設定します。このウィンドウでは次のプロパティ ノードが表示されます。
コード ページ
ディレクトリ
全般
リレーショナル制約
セキュリティ
コード ページ
このセクションでは、コード ページのプロパティ設定について説明します。
データベース コード ページ
PCC 接続エンコード
メモ: データベース エンジンは、アプリケーションがデータベースに追加するデータおよびメタデータのエンコードを検証しません。エンジンは、『Advanced Operations Guide』のデータベース コード ページとクライアント エンコードで説明されているように、すべてのテキスト データが、クライアントによってサーバーまたはクライアント データベースのコード ページのエンコードに変換されていることを前提としています。
データベース コード ページ
このプロパティは、メタデータで使用するエンコードを指定し、DBNAMES.cfg に格納されます。このプロパティはデータベースに適用されます。つまり、データベースとデータをやり取りするすべてのクライアント アプリケーションに影響する可能性があります。PSQL データベース エンジンとクライアント アプリケーション間で互換性のあるエンコードを確立する必要があります。これを行うさまざまな方法については、『Advanced Operations Guide』のデータベース コード ページとクライアント エンコードを参照してください。
メモ: データベース コード ページの変更では、データベースの既存のデータやメタデータは変換しません。データが不正になることを防ぐには、コード ページ設定が、データベース内の既存のデータやメタデータの現状のエンコードと必ず一致するようにしてください。
データベース コード ページは、特に、異なる OS エンコードを使用して PSQL DDF を手動で別のプラットフォームへコピーしながら、データベース エンジンにメタデータを正しく変換させたい場合に役立ちます。
デフォルトのコード ページは "サーバーのデフォルト" で、データベース エンジン実行中のサーバーのオペレーティング システム コード ページを意味します。"コード ページの変更" では設定に関する追加情報を提供し、特定のコード ページを選択することができます。ただし、"コード ページの変更" が行えるのは Linux 版のみです。
PCC 接続エンコード
PCC それ自体はデータベース エンジンのクライアント アプリケーションです。クライアントとして、PCC では、各データベース セッションで PCC がメタデータおよびデータを読み取りまたは追加する際に使用するコード ページ(エンコード)を指定することができます。既存データベースのデフォルトでは、PCC が実行されているマシンのエンコードを使用します。これは、PCC の旧来の動作です。新しいデータベースのデフォルトでは、自動変換を使用します。
次の表では、[PCC 接続エンコード]と[データベース コード ページ]の設定の相互の影響を説明します。
PCC 接続エンコードが特定のエンコードに設定されている
PCC 接続エンコードが "自動変換" に設定されている
PCC はデータベース コード ページを無視し、指定されたエンコードを使用してデータとメタデータを読み書きします。
これは、PCC の旧来の動作です。
PCC およびデータベースは自動的に適合するエンコードを確立します。
データベースのメタデータとデータは、データベース コード ページに指定されたエンコードから PCC が実行されているシステムのエンコードに変換されます。
メモ: [PCC 接続エンコード]は PCC にのみ適用されます。ほかのクライアント アプリケーションには影響しません。
データベース内に OEM 文字データがある場合、旧来の解決法は DSN を使用する ODBC のようなアクセス方法を使用して OEM/ANSI 変換を指定することでした。このバージョンでは、データベースに OEM コード ページを設定し、アクセス方法で自動変換を使用することが可能になりました。『ODBC Guide』の自動も参照してください。
ディレクトリ
このディレクトリのプロパティ設定は、一定のタイプのファイルが存在する物理ストレージ上の場所を指定します。
辞書のロケーション
データ ディレクトリ
辞書のロケーション
この場所は、辞書ファイル(DDF)が存在する物理的な保管場所を指定します。この場所は、接続しているサーバーと同じサーバーで、データベース エンジンが実行されているサーバーにある必要があります。場所の形式は、サーバー マシンで直接作業しているような形式にする必要があります。
Windows オペレーティング システムの場合は、drive:\path という形式でパスを入力します。drive はサーバーのドライブ名です。
Linux の場合、ルートを基準とする標準の Linux パス形式を入力します。
たとえば、データベース エンジンを実行中の Windows サーバーに接続しているワークステーションを使用していて、サーバーの C:\ ドライブの mydata フォルダーに新規データベースを作成したいとすると、ロケーションに「c:\mydata」と入力します。サーバーの C:\ ドライブをローカル ネットワーク ドライブ(たとえば、F:\)にマップしていたとしても、このように入力します。
データ ディレクトリ
[データ ディレクトリ]フィールドのリストでは、データ ファイルが存在する物理ストレージ上の場所を指定します。[新規作成]をクリックして新規リソースを追加します。[除去]をクリックすると、データ ファイルの場所をリストから削除することができます。データ ファイルの場所は、データベース エンジンが起動している同じサーバー上でなければなりません。
[辞書のロケーション]についても同じ方法で場所を指定してください。
全般
[全般の設定]には次のプロパティ設定が含まれています。
バウンド データベース
整合性の設定
長いメタデータ(メタデータ バージョン 2)
リレーショナル制約
バウンド データベース
データベースが、バインドされているかどうかを示します。データベースをバインドすると、DDF またはデータ ファイルが別のデータベースによって使用されることを防ぎ、データ ファイルが同一データベース内で複数の別のテーブル定義を持つことを防ぎます。
バウンド データベースの詳細については、バウンド データベースと整合性の設定を参照してください。
整合性の設定
データベースにセキュリティ、RI、トリガーなどの整合性制約を設定するかどうかを指定します。これらの制約は、データ ファイルへの ODBC/SQL アクセスだけでなく、Btrieve アクセスにも適用されます。
参照整合性の設定および Btrieve およびリレーショナル制約間の相互作用を参照してください。
長いメタデータ(メタデータ バージョン 2)
このプロパティは読み取り専用で、データベースが作成されたときにメタデータ バージョン 2 が指定されたかどうかを示します。指定されている場合は、"長いメタデータ" オプションが選択されていることになります。"長いメタデータ" は メタデータ バージョン 2 の別称のためです。
リレーショナル制約
[リレーショナル制約]には、データベースに効力のあるリレーショナル制約が行列形式で一覧表示されます。Btrieve およびリレーショナル制約間の相互作用を参照してください。
セキュリティ
[セキュリティ]には、[データベース セキュリティ]タブおよび[Btrieve セキュリティ]タブにそれぞれのプロパティ設定が含まれています。セキュリティの完全な説明については、PSQL セキュリティを参照してください。
[データベースの新規作成]GUI のリファレンス
次の図は、新規データベースを作成する場合に使用するダイアログ ボックスです。下の表は図の GUI オブジェクトの説明です。(新規データベースを作成するにはも参照してください。)
スクリーンショット上のそれぞれの領域をクリックするとその詳細が表示されます。
図 16 [データベースの新規作成]ダイアログ ボックス
 
 
表 9 [データベースの新規作成]GUI の要素
要素
説明
関連情報
データベース名
PCC 内のデータベース一覧に表示されるデータベースの名前。
メモ:このデータベース名を既存の DSN と同じにすることはできません。
 
場所
この場所は、接続しているサーバーと同じサーバーで、データベース エンジンが実行されているサーバーにある必要があります。場所は、サーバー マシンで直接作業しているような形式で指定する必要があります。
 
バウンド
データベースが、バインドされているかどうかを示します。データベースをバインドすると、DDF またはデータ ファイルが別のデータベースによって使用されることを防ぎ、データ ファイルが同一データベース内で複数の別のテーブル定義を持つことを防ぎます。
バウンド データベースの詳細については、バウンド データベースと整合性の設定を参照してください。
 
辞書ファイルの作成(存在しない場合)
データベースと共にデータ辞書ファイル(DDF)を作成するかどうかを指定します。データにリレーショナル(SQL)アクセスするには、辞書ファイルが必要です。
デフォルトでは、辞書ファイルとデータ ファイルは同じ場所に作成されます。データベースを作成後、これらの種類のファイルには別の場所を指定することができます。
通常、DDF ファイルを作成しないことを選択する唯一の状況は、既に DDF が存在する名前付きデータベースでないレガシー データベースがあって、そのデータベースにデータベース名を作成している場合のみです。このような状況下では、データベース エンジンは新しいデータベース名を既存の DDF と関連付けます。
 
(図 16 に戻る)
関係整合性の設定
データベースに整合性制約(セキュリティ、RI、トリガー)を設定するかどうかを指定します。これらの制約は、データ ファイルへの ODBC/SQL アクセスだけでなく、Btrieve アクセスにも適用されます。
 
長いメタデータ(メタデータ バージョン 2)
データベース エンジンでは、メタデータでバージョン 1(V1)とバージョン 2(V2)という 2 つのバージョンをサポートします。V2 メタデータの別称は "長いメタデータ" です。
メタデータのバージョンはデータベースのプロパティで、そのデータベース内のすべてのテーブルに適用されます。データベースではメタデータ バージョン 1 を使用するテーブルとメタデータ バージョン 2 を使用するテーブルを一緒に使用することはできません。異なるバージョンのメタデータの DDF はそれぞれ情報をやり取りすることができません。
ODBC Guide』の SQL 文法のサポート
SQL Engine Reference』のシステム テーブル
 
データベース コード ページ
データベースのコード ページ プロパティを指定します。デフォルトは、"サーバーのデフォルト" で、サーバーのデフォルト システム コード ページを意味します。
このプロパティの詳細については、「関連情報」列を参照してください。
 
32 ビット エンジン DSN の作成
ODBC アクセスを行うには、データベース名を指すデータ ソース名(DSN)を設定する必要があります。デフォルトで、新しい DSN の名前はデータベース名と同じになります。複数の DSN が同じ名前付きデータベースを指すことができます。
デフォルトでは、エンコード変換オプション "なし" で DSN を作成します。
メモ:作成する DSN は 32 ビット エンジン DSN である必要があります。PCC では 64 ビット DSN を作成できません。
ODBC インターフェイス ユーティリティを使用して 64 ビット DSN を作成します(Windows の ODBC アドミニストレータなど)。DSN 名は、ビット数が同じであれば固有の名前でなければなりません。32 ビット DSN と 64 ビット DSN は、ビット数が異なるのでそれぞれ同じ名前を持つことができます。
ODBC Guide』の自動
PSQL データベースの作成、編集、削除、および修復
データベースに関連する作業は次のとおりです。
新規データベースを作成するには
データベースのプロパティを変更するには
データベースを削除するには
データベース名を修復するには
名前付きデータベースの概念については、『Advanced Operations Guide』の PSQL データベースの概念を参照してください。
新規データベースを作成するには
メモ: Linux または OS X の場合、データベースを作成するディレクトリのオーナーは psql にする必要があります。そうしない場合は、データベースを作成しようとしても、エラー メッセージ、7039:辞書パスが不正です。が返されます。chown コマンドを使用してディレクトリのオーナーを変更してください。具体的には、「chown psql ディレクトリ名」と指定します。
1 PCC の PSQL エクスプローラーで、データベースを新規作成するデータベース エンジンを右クリックします。
2 新規作成]>[データベース]の順にクリックします。
3 データベースの新規作成]ダイアログ ボックスにデータベースの名前と場所を入力します(表 1 識別子の種類別の制限を参照)。
既存の DSN と同じ名前にすることはできません。また、同じディレクトリに、ファイル名が同一で拡張子のみが異なるようなファイルを置くことはできません。たとえば、 invoice.btr と invoice.mkd を同じディレクトリに置くことはできません。この制限がある理由は、本データベース エンジンがファイル名の拡張子を無視するので invoice.btr と invoice.mkd を同じファイルと認識してしまうためです。
4 データベース オプションと DSN オプションを設定します。オプションに関する情報については、[データベースの新規作成]GUI のリファレンスを参照してください。
データベースのプロパティを変更するには
1 PCC PSQL エクスプローラーで、データベース エンジンを右クリックして[プロパティ]を選択します。
2 プロパティ]ダイアログの一覧から、設定を管理する項目をクリックします。
コード ページ
ディレクトリ
全般
リレーショナル制約
セキュリティ
3 必要に応じプロパティを設定します。
データベースを削除するには
現在ログインしているデータベースを削除することはできません。データベース エンジンからログアウトするにはを参照してください。
データベース セキュリティが "混合" または "データベース" に設定されている場合は、セキュリティを解除した後にデータベースを削除できるようになります。PSQL エクスプローラーを使用してセキュリティを無効にするにはおよび SQL を使ってセキュリティをオフにするにはを参照してください。
データベースを削除する際に、関連付けられている DSN を一緒に削除する場合は、[ウィンドウ]>[設定]>[PSQL]>[全般の設定]から、[関連付けられている DSN エントリは常に削除されます。]オプションを選択します。
1 PCC の PSQL エクスプローラーで、削除するデータベースを右クリックします。
2 削除]をクリックします。
3 [項目の削除]ダイアログで、以下のいずれかをクリックします。
はい、ただし、データベース名のみ - dbnames.cfg からデータベース名のみを削除します。
はい、データベース名と DDF – データベース名、および関連付けられている DDF ファイルを削除します。
いいえ - 削除しないでキャンセルします。
メモ: データベースを削除しても、ユーザー データ ファイルに影響はありません。
データベース名を修復するには
あるデータベースのテーブル(データ ファイル)を、新規作成した別名のデータベースで使用しようとすると、その新しいデータベース用としてテーブルを開くことができないことがあります。場合によっては、そのテーブルは元のバインドされているデータベース名を持っている可能性があります。たとえば、元のデータベースで、バインドが設定されている、または参照整合性が設定されていると、データ ファイルはその元のデータベース名にバインドされますバウンド データベースと整合性の設定も参照してください。
新しいデータベース用にそれらのテーブルを開くことができるようにするには、その新しいデータベースのデータベース名を修復する必要があります。修復を行うと、テーブルは新しいデータベースと関連付けられます。
1 PCC の PSQL エクスプローラーで、データベース ノードを展開し、修復対象のデータベース名を右クリックします。
2 データベース名の修復]をクリックします。
次の表では、データベース、テーブル、あるいはその両方に対するセキュリティ設定に応じた必要な作業(ある場合)について説明します。セキュリティの作業も参照してください。
セキュリティ設定
必要な作業
なし
なし。データベース名の修復を実行します。それ以外の作業は必要ありません。
データベース セキュリティ
ユーザー名を Master とし、パスワードを提供する必要があります。
Advanced Operations Guide』のリレーショナル エンジンのセキュリティ モデルも参照してください。
Btrieve セキュリティ - クラシック
データベース エンジンがリモート サーバー上で実行されており、オペレーティング システムのユーザー名とパスワードがローカル マシンとリモート サーバーとで異なっている場合は、そのリモート サーバー用のユーザー名とパスワードを提供する必要があります。
Advanced Operations Guide』の Btrieve のクラシック セキュリティも参照してください。
Btrieve セキュリティ - 混合
テーブルのデータ ディレクトリが DEFAULTDB データベースに追加されている必要があります。『Advanced Operations Guide』のデフォルトのデータベースと現在のデータベースを参照してください。
さらに、データベースに定義されているユーザー名が、オペレーティング システムに定義されているユーザー名と完全に一致するなど、混合セキュリティのその他の面も適用されます。『Advanced Operations Guide』の Btrieve の混合セキュリティを参照してください。
Btrieve セキュリティ データベース
データベース セキュリティが有効になっている(Master パスワードが指定されている)場合は、ほかにデータベースの Btrieve セキュリティに対して必要な要件はありません。Master 用の権限で十分です。
Advanced Operations Guide』の Btrieve ファイルのデータベース セキュリティも参照してください。
テーブルのオーナー ネーム
テーブルにオーナー ネームが設定されている場合、データベース名の修復の実行時にそのオーナー ネームの入力が要求されます(オーナー ネームに対して[オーナー ネームなしの読み込み専用アクセスを許可する]オプションが指定されている場合を除く)。『Advanced Operations Guide』のオーナー ネームの管理も参照してください。
テーブルごとにオーナー ネームを提供するか、あるいは一連のテーブルに関連付けられている全オーナー ネームのリスト(オーナー ネーム間はカンマとスペースで区切る)を提供することができます。デフォルトで、オーナー ネームはアスタリスクで表示されます。オーナー ネームをプレーン テキストとして表示させたい場合は、[オーナー ネームを表示する]オプションを選択します。
スキップ]ボタンを使用すると、特定のテーブルについてオーナー ネームの提供を省略することができます。すべてのテーブルについて 1 つのオーナー ネームのみを使用する場合は、[オーナー ネームについては今後このメッセージを表示しない。必要とするオーナー ネームが不明なテーブルはスキップされる]オプションを選択して[スキップ]をクリックします。
スキップされたテーブル数は、修復操作の最後にダイアログ ボックスで表示されます。スキップされたテーブル名については、PCC のログに書き込まれます。
テーブル
テーブルは、データベースがデータを保存するオブジェクトです。PSQL では、データ テーブルとシステム テーブルの 2 種類のテーブルを扱います。データ テーブルはユーザーによって作成されます。テーブルは作成後、それにデータを入れるまでは空です。システム テーブルは、必要に応じて PSQL データベースによって作成され、データが入れられます。
データベース テーブル
データ テーブルの完全な説明については、Table Editor を参照してください。また、そのセクションでは、テーブルの作成と削除、および列や外部キーなどの操作についても説明されています。
システム テーブル
システム テーブルは PSQL エクスプローラーのシステム オブジェクト ノードの下に表示されます。その内容は、テーブルのプロパティを表示するにはに説明されているので、ご確認いただけます。
テーブルのプロパティ
テーブル プロパティは、テーブルに関する情報を提供します。別個のタブにより、全般的なプロパティ、列の情報、およびインデックスの情報が表示できます。[全般]タブで一覧できるプロパティについて、次の表で説明します。
表 10 [全般]タブのテーブル プロパティ
パラメーター
説明
テーブル名
データベース定義のとおりにテーブルの名前を表示します。
テーブルの場所
テーブルに関連するデータ ファイルの物理的な場所を表示します。
辞書パス
データベースの DDF ファイルのロケーションを表示します。
ファイル バージョン
データ ファイルのファイル形式バージョンを表示します。
レコード長
データ ファイルのレコード長を表示します。
ページ サイズ
データ ファイルのページ サイズ(バイト単位)を表示します。ページ サイズにより、テーブル内で定義可能なインデックス セグメントの最大数が決まります。
レコード数
データ ファイルに現在あるレコード数を表示します。
インデックス数
テーブルに定義されたインデックス数を表示します。
予約重複ポインター数
追加できるリンク済み重複インデックス数を表示します。
未使用ページ数
プリアロケートされたページ数を表示します。プリアロケートが有効な場合、データ ファイル作成時に、MicroKernel により特定のページ数がプリアロケートされます。プリアロケートにより、MicroKernel で必要とするデータ ファイルのためのディスク容量が確保されます。
可変長レコード
データ ファイルに可変長レコードがあるかどうかを表示します。
可変長レコードのブランク トランケーション
ブランク トランケーションが可能かどうかを表示します。可能な場合、MicroKernel により可変長レコードの空白が切り捨てられます。ブランク トランケーションは、可変長レコードを[はい]、データ圧縮を[いいえ]に設定してある場合にのみ有効です。
レコード圧縮
レコード圧縮が可能かどうかを表示します。可能な場合、MicroKernel により、データ ファイルに挿入される各レコードが圧縮されます。『Advanced Operations Guide』のレコードおよびページ圧縮を参照してください。
キー オンリー ファイル
存在する場合には、テーブルのキーオンリー ファイルの名前を表示します。キーオンリー ファイルにはデータ レコードは含まれていませんが、別の Btrieve ファイルのインデックスとして役に立ちます。
インデックス バランスの実行
インデックス バランスが有効かどうかを表示します。
空きスペース スレッショルド
データ ファイルに空きスペース スレッショルドがある場合、そのパーセンテージ(5、10、20、または 30)を表示します。データベース エンジンでは、レコードの可変長部分が、固定長部分(データ ページ)とは別に、専用のページ(可変ページ)に保存されます。
データベース エンジンでは、スレッショルドにより既存の可変ページにデータを追加するか、ページを新規作成するかが決定されます。空きスペース スレッショルドを大きくすると、可変長レコードが複数のページにわたって断片化するのを抑えることができますが、より多くのディスク容量が必要になります。
ACS を使用する
テーブルでソートを行う場合に、オルタネート コレーティング シーケンスを使用するかどうかを表示。
システム データ キー
データ ファイルのシステム データ キーが有効かどうかを表示。
ページ圧縮
ページ圧縮が可能かどうかを表示します。『Advanced Operations Guide』のレコードおよびページ圧縮を参照してください。
テーブルのプロパティを表示するには
1 PSQL エクスプローラー で特定のデータベースのテーブル ノードを展開します。
システム テーブルに関心がある場合は、システム オブジェクトの下位にあるテーブルを展開します。
2 目的のテーブルを右クリックし、[プロパティ]をクリックします。
ヒント: テーブル プロパティを使用して、テーブルのインデックス付けされた列の一覧を表示することができます。
テーブルを開くには
1 PSQL エクスプローラー で特定のデータベースのテーブル ノードを展開します。
システム テーブルに関心がある場合は、システム オブジェクトの下位にあるテーブルを展開します。
2 作業対象のテーブルを右クリックし、[開く]または[新しいウィンドウで開く]をクリックします。
この操作では、SELECT * from table_name クエリを実行します。
テーブルを削除するには
1 PSQL エクスプローラー でデータベースのテーブル ノードを展開します。
2 目的のテーブルを右クリックし、[削除]をクリックします。
スキーマの管理
スキーマは、メタデータ、つまりデータに関するデータです。PSQL を Btrieve トランザクショナル データベースとして使用する場合、明示的なスキーマは必要ありませんが、少量のメタデータが Btrieve ファイル自体に格納されるほか、MicroKernel エンジンの実行時は MicroKernel エンジンの中に格納されます。これに対し、PSQL リレーショナル データベースでは、データを保管および管理するのに使用されるすべての情報はスキーマに格納されます。このリレーショナル情報はデータ辞書ファイル(DDF)に格納されます。本 SQL エンジンが正しく動作し、かつ高いパフォーマンスを発揮するかどうかは、DDF が有効かつ正確であるかどうかによって決まります。このセクションの情報を使用することで、無効または不完全な DDF を検出し、そのような DDF を修正するために実行できる処置を決定することができます。
DDF では、テーブルおよびフィールドの構造と以下の特性/機能を定義します。
テーブル属性と列属性
列インデックスとインデックス属性
主キーや外部キーなどのテーブル制約
ストアド プロシージャ、トリガー、ユーザー定義関数、およびビュー
データベース セキュリティ設定
スキーマは再利用や保管のためにファイルにエクスポートすることができます。PCC で、データベースを右クリックし、[スキーマのエクスポート]を選択すると、データベース スキーマのエクスポート ウィザードが表示されます。テーブルを右クリックして[テーブル スキーマのエクスポート]を選択すると、ダイアログが表示されます。どちらの場合も、ファイル拡張子 .sql とする、スキーマがエクスポートされたファイルを作成します。このファイルは SQL スクリプトと呼ばれます。デフォルトのエクスポート場所は、C:\Users\ユーザー アカウント>です。
エクスポートによって作成された SQL スクリプトは、次の方法で使用できます。
PCC でデータベースを右クリックし、[スキーマのインポート]を選択してスクリプトを実行します。
PCC で[ファイル]>[開く]を使用し、スクリプトを SQL Editor で開いて実行します。
テキスト エディターを使ってスクリプトの全部または一部をコピーし、SQL Editor に入力して実行します。
pvddl を使って、コマンド プロンプトでこのスクリプトの全部または一部を実行します。
このセクションの残り部分では、以下の項目について説明します。
データベース スキーマのエクスポート オプション
テーブル スキーマのエクスポート オプション
スキーマのエクスポート作業とインポート作業
エクスポート後のデータベース スキーマ ファイルの一般的な使用法
特殊なケース:セキュリティで保護されたデータベース スキーマの操作
データベース スキーマのエクスポート オプション
データベース スキーマのエクスポート ウィザードには、PSQL のメタデータをエクスポートするための以下のような設定が用意されています。
CREATE/ALTER ステートメントに IN DICTIONARY を含める
データベース スキーマをエクスポートするときに、CREATE および ALTER ステートメントに IN DICTIONARY キーワードを含めておくと、エクスポートされたスキーマを使って新しい DDF のセットにスキーマを再作成する際、基となるデータ ファイルを作成しないようにすることができます。このオプションを選択しない場合は、スキーマをインポートすると、DDF のメタデータ定義だけでなく各テーブルの空のデータ ファイルも作成されます。
この設定を使用する場合は、データ ファイルを新しいデータベースの場所にコピーしてからスキーマをインポートします。そうすると、SQL スクリプトがそれらのファイルの DDF にメタデータを再作成できます。
セキュリティ スキーマ(ユーザー/グループ/アクセス許可)を含める
スキーマにより、定義されているすべてのユーザー、グループ、および権限などのセキュリティ設定を取り込むことができます。データベースが過去にセキュリティを使用していたが、現在それを有効にしていない場合でも、このスキーマのメタデータは存在する可能性があります。インポートされるセキュリティ設定を別のデータベースで使用できるようにするには、スキーマをインポートする前に、そのデータベースでセキュリティを有効にしておく必要があります。有効にしておかないと、インポートが完了した場合でもエラー メッセージが返されます。
完了時に内部エクスポート テーブルを削除する(推奨)
内部エクスポート テーブルの削除はデフォルトで選択されています。このオプションは、スキーマのエクスポート時に生成されたファイルを削除します。これらのファイルは、残しておけばトラブルシューティング時に役立ちますが、通常の使用状況下ではクリーンアップすることをお勧めします。生成されるテーブルには、文字列 x$Dump で始まる名前が付けられます。
スクリプト ファイルのエンコード
エクスポート先のパス名を指定するフィールド([エクスポート先])の下で、ファイル エンコードの初期設定に記載されたオプションのリストから、スクリプト ファイルのエンコードを選択できます。また、デフォルト エンコードを変更することもできます。
テーブル スキーマのエクスポート オプション
[テーブル スキーマのエクスポート]ダイアログには、テーブルのメタデータをエクスポートするための以下のようなオプションが用意されています。
IN DICTIONARY なしで CREATE TABLE ステートメントをエクスポートする。これはデフォルトです。
CREATE TABLE ステートメントに IN DICTIONARY 句を追加する。
ファイル エンコードの初期設定に記載されたオプションのリストから、スクリプト ファイルのエンコードを選択する。このダイアログには、デフォルトのエンコードの初期設定を開いて変更するためのオプションがあります。
以下は IN DICTIONARY 句の使用例を示しています。
IN DICTIONARY
このオプションを選択する場合は、必ずすべてのデータ ファイルを新しいデータベースの場所にコピーしたうえで、その新しい場所でスクリプトを実行してください。データ ファイルは、テーブル作成の成功に必要不可欠です。詳細については、『SQL Engine Reference』の IN DICTIONARY を参照してください。
CREATE TABLE "Course" IN DICTIONARY USING 'Course.mkd' (
 "Name" CHAR(7) NOT NULL CASE ,
 "Description" CHAR(50) CASE ,
 "Credit_Hours" USMALLINT,
 "Dept_Name" CHAR(20) NOT NULL CASE
);
CREATE UNIQUE INDEX "Course_Name" IN DICTIONARY ON "Course"("Name");
CREATE INDEX "DeptName" IN DICTIONARY ON "Course"("Dept_Name");
スキーマのエクスポート作業とインポート作業
以下の手順では、PCC を使ってデータベース スキーマをエクスポートしたりインポートしたりする方法を示します。
データベース スキーマをエクスポートするには
データベース スキーマをインポートするには
テーブル スキーマをエクスポートするには
テーブル スキーマをインポートするには
データベース スキーマをエクスポートするには
1 PCC でデータベースを右クリックし、[スキーマのエクスポート]を選択します。
2 エクスポート先のファイルの名前を入力します。
3 エクスポート オプションを選択します。
4 エクスポートの開始]をクリックします。
エクスポートが完了したら、[再エクスポート]ボタンを使用し、ファイル名を変更することで追加のコピーを作成できます。
5 次へ]をクリックします。
6 [エクスポートの詳細]パネルにメッセージの一覧が表示されます。自身に関係するエントリが見つかった場合は、スキーマのエクスポートおよびインポートの問題のトラブルシューティングを参照してください。
7 エクスポートしたスクリプトやエクスポート ログを開くには、対応する[表示]ボタンをクリックします。
8 作業が終わったら、[完了]をクリックします。
データベース スキーマをインポートするには
スキーマで使用するデータ ファイルをコピーしたら、それらのファイルを必ず新しい場所に置いてから、スキーマをインポートしてください。また、スキーマをインポートする際には、必ず IN DICTIONARY オプションを指定してください。
1 PCC で、データベースを右クリックし、[スキーマのインポート]を選択します。
2 データベース スキーマのインポート ウィザードで、[参照]ボタンを使ってスクリプト ファイルを選択するか、[インポート元]フィールドにパス名を入力します。
3 インポートの開始]をクリックします。
4 スキーマがインポートされたら、[次へ]をクリックします。
5 検証手順では、新しいデータベースをスキーマのエクスポート元のデータベースと比較することによって、チェックを実行するオプションがあります。
検証をスキップするには、[次へ]をクリックします。
ここには、エクスポートされたスキーマに含まれるデータベースの名前が自動的に入力されます。別のデータベースに照らして検証するには、その別のデータベース名を入力するか、[データベースの選択]ボタンを使って、サーバーが認識するデータベースの一覧からその別のデータベースを選択します。処理するには、[検証の開始]をクリックします。
6 検証により、メッセージの一覧が表示されます。自身に関係するエントリが見つかった場合は、スキーマのエクスポートおよびインポートの問題のトラブルシューティングを参照してください。
7 次へ]をクリックします。
8 [インポートの詳細]に結果がまとめられます。インポート ログを開くには、対応する[表示]ボタンをクリックします。
インポート ログには、インポート中に表示されたメッセージと、メッセージを返した SQL ステートメントを含むその他の詳細も格納されます。ログには検証結果も記録されます。
9 作業が終わったら、[完了]をクリックします。
メモ: インポートするスキーマが既に存在するテーブルを作成しようとしても、スキーマの CREATE ステートメントは無視され、既存のテーブルは影響を受けません。
テーブル スキーマをエクスポートするには
1 PCC でテーブルを選択します。複数のテーブルを選択するには、Shift または Ctrl キーを押しながらクリックします。
2 選択したテーブルを右クリックし、[テーブル スキーマのエクスポート]を選択します。
3 エクスポート先のスクリプト ファイルの名前を入力します。
4 IN DICTIONARY 句を使用するかどうかを選択し、エンコードを確認します。
5 OK]をクリックします。
テーブル スキーマをインポートするには
テーブルのデータ ファイルがコピーされている場合は、そのファイルを必ず新しい場所に置いてから、スキーマをインポートしてください。また、スキーマをインポートする際には、必ず IN DICTIONARY オプションを指定してください。
1 PCC で、データベースを右クリックし、[スキーマのインポート]を選択します。
2 データベース スキーマのインポート ウィザードで、[参照]ボタンを使ってスクリプト ファイルを選択するか、[インポート元]フィールドにパス名を入力します。
3 インポートの開始]をクリックします。
4 スキーマがインポートされたら、[次へ]をクリックします。
5 検証手順では、新しいデータベースをスキーマのエクスポート元のデータベースと比較することによって、チェックを実行するオプションがあります。
検証をスキップするには、[次へ]をクリックします。
ここには、エクスポートされたスキーマに含まれるデータベースの名前が自動的に入力されます。別のデータベースに照らして検証するには、その別のデータベース名を入力するか、[データベースの選択]ボタンを使って、サーバーが認識するデータベースの一覧からその別のデータベースを選択します。処理するには、[検証の開始]をクリックします。
6 検証により、メッセージの一覧が表示されます。自身に関係するエントリが見つかった場合は、スキーマのエクスポートおよびインポートの問題のトラブルシューティングを参照してください。
7 次へ]をクリックします。
8 [インポートの詳細]に結果がまとめられます。インポート ログを開くには、対応する[表示]ボタンをクリックします。
インポート ログには、インポート中に表示されたメッセージと、メッセージを返した SQL ステートメントを含むその他の詳細も格納されます。ログには検証結果も記録されます。
9 作業が終わったら、[完了]をクリックします。
メモ: インポートするスキーマが既に存在するテーブルを作成しようとしても、スキーマの CREATE ステートメントは無視され、既存のテーブルは影響を受けません。
エクスポート後のデータベース スキーマ ファイルの一般的な使用法
このセクションでは、 データベース スキーマの一般的な使用法について説明します。
データベース全体をコピーするには
DDF のみをコピーして空のデータ ファイルを作成するには
v1 形式から v2 形式にデータベースを移行するには
データベース スキーマの整合性を検証するには
データベース全体をコピーするには
データベース スキーマをインポートすることで、エクスポート元のデータベースの完全コピーを作成できます。このようなコピーは、テストを行ったり、アプリケーション配布の一環として実行時にメタデータを生成したりするために使用できます。
1 IN DICTIONARY オプションを指定して、データベース レベルのスキーマをエクスポートします。
2 新しいデータベースを作成します。新しいデータベースをエクスポート元と同じサーバーに作成する場合は、異なる名前にする必要があります。新規データベースを作成するにはを参照してください。
3 元のデータベースの全データ ファイルのコピーを作成します。
4 データ ファイルのコピーを新しいデータベースの場所に置きます。必ずこの手順を行ってからインポートを行ってください。
5 新しいデータベースにスキーマをインポートします。
6 新旧のデータベースが同じサーバーにある場合は、新データベースを旧データベースに照らして検証することで、無効なテーブル定義やスキーマの不一致の問題など、不一致がないかどうかをチェックできます。
DDF のみをコピーして空のデータ ファイルを作成するには
機密性のため、テクニカル サポートがデータ ファイルを共有できないようになっているなどのシナリオでは、スキーマのインポートにより DDF と空のファイルが作成されるよう、データ ファイルのコピーをスキップすることができます。
1 IN DICTIONARY オプションを指定せずに、データベース レベルのスキーマをエクスポートします。
2 新しいデータベースを作成します。新しいデータベースをエクスポート元と同じサーバーに作成する場合は、異なる名前にする必要があります。新規データベースを作成するにはを参照してください。
3 新しいデータベースにスキーマをインポートします。空のデータ ファイルが自動的に作成されます。
4 新旧のデータベースが同じサーバーにある場合は、新データベースを旧データベースに照らして検証することで、無効なテーブル定義などの不一致がないかどうかをチェックできます。
v1 形式から v2 形式にデータベースを移行するには
v1 形式から v2 形式にデータベースを移行すると、長い識別子名、ビューおよびストアド プロシージャの実行権限、データベース オブジェクトの最大数の拡張など v2 メタデータの機能をお使いのアプリケーションと環境で利用できるようになります。
v1 形式から v2 形式にデータベースを移行する手順は、データベースをコピーする場合と似ていますが、相違点は、新しいデータベースを作成する際に長いメタデータ オプションを選択する必要があることです。
v1 形式から v2 形式への移行を行う際は、v2 データベースをその基となった v1 と比較する検証手順を実行する必要があります。検証に成功した場合は、新データベースでも旧データベースと同じ動作を期待できることになります。
データベース スキーマの整合性を検証するには
多くのお客様は 20 ~ 30 年の長きにわたって PSQL データベースをお使いです。スキーマは、レガシー ツールやサード パーティ製のユーティリティを使用して、あるいは手書きによって作成されている可能性があります。このようなデータベースには、無効なテーブル定義があったり、データ ファイルに一致しない定義があったりします。エクスポートおよびインポート処理では、このような欠陥のある定義が検出されるので、それらの定義を修正することで、PSQL エンジンの機能およびパフォーマンスを最適化することができます。
1 IN DICTIONARY オプションを指定して、データベース レベルのスキーマをエクスポートします。警告やエラーがないかどうかエクスポート ログを確認します。
2 旧データベースと同じサーバーに、旧データベースと異なる名前で新データベースを作成します。
3 元のデータベースの全データ ファイルのコピーを作成します。
4 データ ファイルのコピーを新しいデータベースの場所に置きます。
5 新しいデータベースにスキーマをインポートします。
6 検証手順を実行します。
7 インポートや検証に関する警告やエラー メッセージがないかどうか、インポート ログを確認します。そのようなエントリが見つかった場合は、その意味をスキーマのエクスポートおよびインポートの問題のトラブルシューティングで確認してください。
特殊なケース:セキュリティで保護されたデータベース スキーマの操作
エクスポート操作を行うには、CREATE データベース権限が付与されたグループのユーザー アカウントが必要です。スキーマをエクスポートする前に、そのようなアカウントでログインするか、そのようなアカウントのユーザー名とパスワードを入力するよう求められることを考慮しておきます。
1 データベース レベルのスキーマをエクスポートします。セキュリティで保護されたデータベースからスキーマをエクスポートする場合は、デフォルトで[セキュリティ スキーマ(ユーザー/グループ/アクセス許可)を含める]オプションが選択されます。
2 スキーマを新しいデータベースにインポートした場合の結果は、その新しいデータベースでセキュリティが有効になっているかどうかによって異なります。
セキュリティが有効になっている場合
スキーマをインポートした後では、データベースが使用可能になります。ただし、以下の点に注意してください。
インポートされるユーザーのパスワードが空になっています。パスワードを設定するには、SQL Editor において、SET PASSWORD FOR 'ユーザー' = 'パスワード' を使用します。
ユーザー名とグループ名が既存のユーザー名とグループ名に一致する場合には、インポートは失敗します。既存のユーザーとグループは変更されません。このエラーはインポート ログに出力されます。
セキュリティが無効になっている場合
セキュリティが無効になっている場合は、以下の現象が発生します。
インポート ログにユーザー、グループ、ユーザー権利、テーブル列の作成エラーが出力されます。
検証手順は提供されません。
スキーマ内の全項目がインポートされ、データベースが使用可能になりますが、セキュリティは無効になっています。
ターゲット データベースのセキュリティを有効にしてスキーマを再インポートすると、既にインポート済みの項目のインポート エラーがログに出力されますが、セキュリティ無効時にインポートできなかったセキュリティ項目はインポートできるようになります。これで、検証手順を使用できるようになります。ただし、検証に成功するのは、元のデータベースにあるユーザー名とパスワードで新しいデータベースにログインした場合に限ります。最初のインポート時であっても、検証で問題が示されなかった場合には、セキュリティが有効になっていたかのようにデータベースが使用可能になります。
特殊なケース:複数のレコード定義またはバリアントのレコード定義の操作
PSQL では 1 つのデータ ファイルに対して複数のテーブル定義を作成できます。たとえば、1 つ目の定義には、データ ファイルの最初のキーに対応する最初の列を ID CHAR(12) として指定できる一方、2 つ目のテーブル定義では、12 文字の ID を小さな列、SequenceNum CHAR(8)、Location CHAR(2)、Zone CHAR(2) の集合として管理できます。PSQL では、USING 句を使って同じデータ ファイルを参照することで、複数のテーブル定義を作成できます。ただし、次の例に示すように、定義同士が両立可能である必要があります。
また、PSQL では、各エントリにレコード型を示す列を追加することで、同じデータ ファイルにさまざまなレコード レイアウトを格納できます。このようなファイルはバリアント レコードがあると呼ばれます。次に例を示します。
CREATE TABLE Vendor USING 'COMPANY.DAT'
  (ID CHAR(12), RecType CHAR(1), V_Name VARCHAR(20), V_City VARCHAR(20), ...)
CREATE TABLE Customer USING 'COMPANY.DAT'
  (ID CHAR(12), RecType CHAR(1), Cust_Type INTEGER, Cust_Contract Char(8), ...)
Vendor テーブルと Customer テーブルはともに company.dat を参照し、両テーブルの定義の最初の 2 つの列は一致していますが、3 つ目以降の列定義は異なっています。これらのテーブルの 2 つのレコード レイアウトは、全体の長さが同じで、かつデータ ファイル内のレコード長も一致している必要があります。テーブル定義には、全体の長さとなるように埋め込むための余分なフィールドも必要なら追加できます。さらに、すべてのバリアント レコードに共通するインデックス定義があるほか、ただ 1 つのテーブル定義で使用されるインデックスもあります。この例では、company.dat にアクセスするアプリケーションは、各レコードのテーブル定義を指定するための正しい RecType 値を送信する必要があります。
データ ファイル内のテーブル定義数が[スキーマのエクスポート]機能によりチェックされます。複数個見つかった場合は、CREATE TABLE ステートメントと、2 つのほとんど同じ CREATE INDEX ステートメント(IN DICTIONARY を一方は含み、他方は含まない点のみが異なる)を使って、スキーマがエクスポートされます。
これら追加の CREATE INDEX ステートメントを使ってスキーマをインポートすると、各テーブルに対して、共通のインデックスと一意のインデックスがともに正常に作成されます。インポートを行うときに、いくつかのタイプのメッセージが記録されます。これらのメッセージはエラーまたは警告としてマークされますが、通常は無視できます。この理由について、Vendor および Customer テーブルで共有される サンプル データ ファイル company.dat を引き続き使った次の例で説明します。これらのテーブルのスキーマを新しいデータベースにインポートすると、以下の現象が発生します。
Vendor テーブルは、IN DICTIONARY を指定しない一連の CREATE INDEX ステートメントで作成されます。
CREIN DICTIONARY を指定した CREATE INDEX ステートメントでは、次のエラー メッセージが生成されます。
[エラー]   [LNA][PSQL][SQL Engine]重複インデックスが存在します。
2 番目の CREATE INDEX ステートメントのセットは、前のステートメントが成功しているため、失敗します。
Customer テーブルが作成される際に、次のような警告が表示されます。
[警告]   [LNA][PSQL][SQL Engine]USING 句内のデータ ファイル 'company.dat' は既に存在しており、テーブル 'Customer' と関連付けられています。
このメッセージは、予想されるように、2 つのテーブル定義が同じデータ ファイルを使用していることを示しています。
Vendor テーブルの作成により company.dat のインデックスが既に作成されているため、IN DICTIONARY を指定しなかった Customer テーブルの CREATE INDEX ステートメントは失敗し、次のエラーが表示されます。
[エラー]   [LNA][PSQL][SQL Engine][Data Record Manager]キー番号パラメーターが不正です(Btrieve エラー 6)
これに対し、IN DICTIONARY を指定した CREATE INDEX ステートメントでは、エラーや警告なしで DDF にインデックスが正しく追加されます。
同じデータ ファイルを使用するバリアント テーブルを操作していることがわかっている場合は、このようなインポート ログ エントリは無視できます。スキーマのインポート ログの検証セクションにこれら以外のエラーまたは警告が出力されていない場合は、テーブルが正しく作成されたことが公式に確定します。
スキーマのエクスポートおよびインポートの問題のトラブルシューティング
データベース スキーマのエクスポートとインポートは、SQL アプリケーションでの予期しない結果や不正な結果を生じ得るメタデータ定義の問題を検出するのに役立ちます。このような問題は通常、標準的な SQL に準拠していない DDF によって発生します。スキーマをエクスポート、インポート、および検証したときに記録された警告メッセージやエラー メッセージを使って、スキーマ定義を評価、修正することができます。
トラブルシューティング処理では、以下の一部または全部を確認、分析するなど、いくつかのステップを実行する場合があります。
スキーマのエクスポートのログ エントリ
スキーマのインポートのログ エントリ
スキーマ検証のログ エントリ
スキーマのエクスポートによって生成されたスクリプト
ソース データベースおよびターゲット データベースのメタデータ定義
このセクションでは、重要なログ エントリの詳細および例、ならびに実行すべきアクションを示します。
スキーマのエクスポートのログ
スキーマのインポートのログ
スキーマ検証のログ
スキーマのエクスポートのログ
スキーマをエクスポートすると、PSQL はデータベースに定義されているオブジェクトごとに SQL ステートメントを生成しようとします。問題のあるオブジェクトについては、調査が必要な潜在的な問題に関する洞察に満ちたメッセージが生成される場合があります。エクスポート中に生成されたメッセージは、データベース スキーマのエクスポート ウィンドウに表示されます。エクスポート後、これらのメッセージは、警告に関連する SQL ステートメントを含むその他の詳細とともに、schema_export.log ファイルにも書き込まれます。特定のテーブルまたは列に関する警告メッセージも、"/* <message> */" という形式のコメント マークが付いて、schema.sql スクリプトに追加されます。
オルタネート コレーティング シーケンス(ACS)
問題:COLLATE 属性のあるテーブル列がある場合は、スキーマのエクスポート時に次の警告が返されます。
[警告] 1 つ以上のテーブルが照合順序 'UPPER.ALT' を使用しています。インポートする前に、このファイルをインポート データベースの場所にコピーする必要があります。
このようなメッセージの 1 つが、データベース内の一意のコレーティング シーケンスごとに入ります。
処置:すべてのコレーション ファイルが新しいデータベースの場所にあることを必ず確認したうえで、スキーマをインポートします。
無効なエントリ
問題:スキーマのエクスポート中、無効なサイズや小数位が検出されると、次のようなメッセージが返されます。
[WARN] Decimal value ignored for integer column <table>.<column>
(整数列 <テーブル>.<列> では小数位は無視されます)
[WARN] Column <table>.<column> has an incorrect size of 0
(列 <テーブル>.<列> には不正なサイズ 0 が設定されています)
最初のメッセージは単に情報を提供するだけであり、何もする必要はありません。2 番目のメッセージは、スキーマがインポートされるときに、指定されたテーブルが作成できないことを示します。
アクション:元のデータベースにある無効なサイズのテーブル定義を修正するには、ALTER TABLE ステートメントを使って列のサイズを修正するか、列を削除します。次に、スキーマを再度エクスポートして、正しい CREATE TABLE ステートメントを生成します。また、元の DDF を変更したくない場合は、エクスポートで生成された schema.sql ファイルを編集して、正しい列サイズを指定することもできます。後者を選択した場合、スキーマのインポートで作成される新しいテーブルは、元のテーブルと一致しないため、検証エラーが生成されます。
重複している列
問題:テーブル定義に同じオフセットで列が複数あり、それらの列の少なくとも 1 つが BIT 型でない場合、スキーマのエクスポートにより次のようなメッセージが返されます。
[WARN] Column <table>.<column> has the same offset as another column that is not type BIT
(列 <テーブル>.<列> は、BIT 型でない別の列と、オフセットが同じです)
1 つの SQL テーブルでは、オフセットが同じ複数の列は、すべて BIT 型でない限り、持つことができません。データの一部を、複数のタイプのクエリで別々の方法で定義する必要がある場合は、複数のテーブル定義を作成するか、ビューを使用します。
処置:このオフセットに対して正しい列を確認し、その他の列を ALTER TABLE ステートメントで削除します。また、元の DDF を変更したくない場合は、エクスポートで生成された schema.sql ファイルを編集して、その他の重複する列を削除することもできます。このような修正を行わない場合、スキーマのインポートで作成される新しいテーブルは、一意のオフセットに作成された列をすべて含むため、検証エラーが生成されます。
Btrieve のヌル キー
問題:古い DDF のインデックスには、データ ファイルにある Btrieve のヌル キーに対応することを示すフラグが設定されている場合があります。PSQL エンジンは、このフラグをレガシー ヌルとして扱うため、使用したり保守したりしなくなりました。スキーマのエクスポートでは、次のようなメッセージが返されます。
[WARN] Btrieve NULL key flag not supported in SQL index <name> on table <name>
(Btrieve のヌル キー フラグはテーブル <名前> の SQL インデックス <名前> では使用できなくなりました)
処置:これは情報メッセージであり、何もする必要はありません。レガシー ヌルと新しい真のヌルの詳細については、『Advanced Operations Guide』のヌル値を参照してください。
スキーマのインポートのログ
インポート中に生成されたメッセージは、データベース スキーマのインポート ウィンドウに表示されます。インポート後、これらのメッセージは、警告に関連する SQL ステートメントを含むその他の詳細とともに、schema_import.log ファイルにも書き込まれます。
このセクションでは、重要なログ エントリの詳細および例、ならびに実行すべきアクションを示します。
SQL エラー
バリアント レコードに関するメッセージ
参照整合性制約
メタデータのバージョン エラー
SQL エラー
問題:schema.sql スクリプトをインポートすると、無効な SQL ステートメントでエラーが返される場合があります。これらのエラーによって、元のデータベースの DDF に指定されたデータベース オブジェクトにあると示された問題には、以下のものがあります。
構文エラー
レコードのキー フィールドに重複する値があります(Btrieve エラー 5)
テーブルまたはオブジェクトがありません
無効な列型です
列またはパラメータ No. 1:列幅にゼロは指定できません
列の長さの上限値を超えました
Btrieve キー定義がインデックス定義と一致しません
これらのエラーが発生する原因の一部は、無効なデータ型や列の長さ、相対パスでないデータ ファイルのパスなど、ソース データベース内の無効なエントリによるものです。一方、前のエラーが原因となって引き起こされるエラーもあります。たとえば、CREATE TABLE が失敗すると、後続の CREATE INDEX ステートメントも失敗します。
処置:メッセージとインポート ログ ファイル内の詳細を確認し、エラーの原因を究明します。必要があれば、エラーに関連するすべての SQL ステートメントを schema.sql ファイルで確認してください。たとえば、CREATE PROCEDURE で生成されたエラーはその 1 行目しかログに記録されませんが、schema.sql にはステートメント全体が格納されています。
バリアント レコードに関するメッセージ
問題:以下のメッセージは通常、データベースにバリアント レコード定義があることを示します。
[警告] [LNA][PSQL][SQL Engine] USING 句内のデータ ファイル '<ファイル名.拡張子>' は既に存在しており、テーブル '<テーブル>' と関連付けられています。
[エラー] [LNA][PSQL][SQL Engine]重複インデックスが存在します。
[エラー] [LNA][PSQL][SQL Engine][Data Record Manager]キー番号パラメーターが不正です(Btrieve エラー 6)
処置:特殊なケース:複数のレコード定義またはバリアントのレコード定義の操作でこれらのメッセージの詳細を確認してください。
参照整合性制約
問題:以下のメッセージは通常、データベースに参照整合性制約があることを示します。
[エラー] [LNA][PSQL][SQL Engine][Data Record Manager] MicroKernel は指定されたファイルを見つけられません(Btrieve エラー 12)。
[LNA][PSQL][SQL Engine][Data Record Manager]RI 定義は同期が取れていません(Btrieve エラー 73)。
通常、これらのエラーが発生するのは、[CREATE/ALTER ステートメントに IN DICTIONARY を含める]オプションを選択したために、スキーマのエクスポートにより外部キーの制約が作成されている場合です。ステータス 12 の場合は、データ ファイルが存在していません。ステータス 73 の場合は、データ ファイルが複数の名前を持つデータベースからコピーされています。
処置:参照整合性が設定されたデータベースの場合は、スキーマのエクスポートを[IN DICTIONARY を含める]オプションを選択せずにやり直して、スキーマを再度インポートする必要があります。そうすることにより、スキーマのインポートでデータ ファイルが作成され、そのデータ ファイル内に参照整合性制約の情報が格納されます。
メタデータのバージョン エラー
問題:以下のメッセージは通常、あなたが V2 メタデータ データベースからスキーマをエクスポートし、そのエクスポートしたスキーマを v1 メタデータ データベースにインポートしようとしていることを示します。
[LNA][PSQL][SQL Engine]テーブル名 longtablenameinv2database が長すぎます。
[LNA][PSQL][SQL Engine][Data Record Manager]この機能は、現メタデータ バージョンではサポートされていません。
これらのエラーが発生するのは、ソース データベースで長いメタデータ オブジェクト名、ビューまたはストアド プロシージャ内での EXECUTE AS、ビューまたはストアド プロシージャ内での GRANT ステートメントなど、v2 メタデータに固有の機能を使用している場合のみです。v2 メタデータの機能を使用していない v2 メタデータ データベースからスキーマをエクスポートし、エクスポートしたスキーマを v1 メタデータ データベースにインポートした場合には、エラーは返されません。
処置:元のデータベースで v2 メタデータを使用している場合は、ターゲット データベースを作成する際にも必ず v2 メタデータを使用してしてください。v2 メタデータの全機能が再作成されるようにするためです。
スキーマ検証のログ
検証中に生成されたメッセージは、[インポートの検証]ウィンドウに表示されます。検証が完了すると、schema_import.log ファイルにおいて、インポート メッセージの後にこれらのメッセージが書き込まれます。
検証処理では、新しいデータベースと元のデータベースを比較するための一連のクエリが実行されます。以下のそれぞれに、欠落しているエントリ、余分なエントリ、不一致のエントリがないかどうかがチェックされます。
テーブル
列と列属性
主キーおよび外部キー
インデックス
ストアド プロシージャ
ビュー
トリガー
ユーザーとグループ(セキュリティが有効になっている場合)
オブジェクトが欠落している場合は、ログの「import」セクションを参照し、そのオブジェクトの作成の失敗に関連したエントリを特定します。このエントリには、SQL ステートメントと、失敗の原因を究明するために生成されたエラーが記載されています。
このセクションでは、重要なログ エントリの詳細および例、ならびに実行すべきアクションを示します。
オフセットの不一致
問題:元のデータベースに、重複する列が含まれるテーブル定義がある場合(スキーマのエクスポートのログを参照)は、新しいデータベース内の対応するテーブルで、すべての列が順次に作成されます。この違いがそのテーブルについてのオフセット不一致エラーに記載されて返されます。
処置:元のデータベースのテーブル定義を修正するか、エクスポートで生成された schema.sql ファイルを編集して、テーブルから重複する列を削除します。
データ型の不一致
問題:レガシー データベースでは、符号なしの INTEGER データ型はサポートされていません。符号なしの 1 バイトの INTEGER として定義されていた一部のテーブル列が、データ型 1 を使い、列フラグに 1 ビットを設定して作成されています。符号なしの INTEGER のサポートが追加されている場合、このような列を適切に定義するにはデータ型 14 を使用します。このデータ型の違いは検証で検出される可能性があります。
処置:特に何らかの対処を行う必要はありません。データ型 14 の新しい列定義は、古い定義とまったく同様に機能します。
属性の欠落
問題:元のデータベースに、大文字と小文字を区別せず、かつオルタネート コレーティング シーケンスのある列を定義している場合、そのような列は新しいデータベースでは大文字と小文字の区別なしのフラグのみが設定されて再作成されます。これら両方の属性を 1 つの列に設定することはできません。このような列に COLLATE 属性が欠落していることが、検証によって検出されます。
処置:元のデータベースのテーブル プロパティをチェックして、列定義に CASE と COLLATE が両方とも設定されていることを確認します。両方とも設定されていれば、特に何らかの対処を行う必要はありません。大文字と小文字の区別がない新しい列定義は、元のデータベースの列定義とまったく同様に機能します。
インデックスの欠落
問題:インデックスの作成が失敗する原因は複数あります。データ ファイルの場所に相対パスでなく絶対パスが使用されていて、[CREATE/ALTER ステートメントに IN DICTIONARY を含める]オプションを選択した場合には、スキーマをインポートすると、インデックスの作成に失敗する可能性があります。また、バリアントのレコード定義がある場合も、同じデータ ファイルの複数のテーブル定義に共通するインデックスが一致しなくなる原因になる可能性があります。
処置:インポートのログを参照し、CREATE INDEX ステートメントに関連したエラーを特定します。ソース データベースまたは schema.sql ファイルに必要な修正を行って、データベースを再度インポートします。
データの作成、インポート、およびエクスポート
PCC を使用して作成したテーブルは、最初は空です。PCC を介して、またはインポートすることによって、これらにデータを追加することができます。PCC にはデータをエクスポートおよびインポートするウィザードがあります。
PCC を使用してデータを作成する
グリッドにデータ行を追加するにはを参照してください。
バルク データ ユーティリティを使用してデータをインポートする
bdu を参照してください。
データ インポート ウィザードを使ったデータのインポート
データのインポート ウィザードでは、テキスト ファイルの区切り文字付きデータを読み取って、そのデータをテーブルへ追加します。このウィザードでは以下の項目について選択を行うことができます。
インポートするデータが含まれるテキスト ファイル
フィールド区切り文字
インポートされるデータのエンコード。このエンコードは、データ エクスポート時に使用したエンコードと一致している必要があります。データ エクスポート ウィザードを使ったデータのエクスポートを参照してください。
エクスポートされたデータの先頭行に列名が含まれているかどうか。列名を先頭行としてエクスポートされたデータの場合は、同じ方法でインポートする必要があります。
制限事項
フィールド区切り文字には、カンマ、コロンまたはタブのいずれかを使用する必要があります。レコードを区切る場合は、キャリッジ リターンとライン フィードを併用する必要があります。
データベース テーブルにデータをインポートするには
1 特定のデータベースの場合、テーブル ノードの下位にあるテーブル名を右クリックします。
これは、これにデータをインポートするテーブルです。システム テーブルに関心がある場合は、システム オブジェクトの下位にあるテーブルを展開します。
2 データのインポート]を選択します。
3 上で述べたインポート特性を指定し、[終了]をクリックします。
データ エクスポート ウィザードを使ったデータのエクスポート
データのエクスポート ウィザードでは、テーブルのデータをテキスト ファイルへエクスポートします。キャリッジ リターンとライン フィードを併用してレコードを区切ります。
このウィザードでは以下の項目を指定します。
データのエクスポート先となるファイルの名前。ディレクトリ パスは既に存在している必要があります。本リリースでは、デフォルトの場所は、現在ログインしているユーザーのホーム ディレクトリと、選択したファイル名および拡張子で構成される、C:\Users\ログイン\ファイル名.拡張子です。
エクスポートの基準となる SQL ステートメント。たとえば、SELECT * FROM t1 はテーブル t1 の全レコードをエクスポートします。
フィールド区切り文字(各レコード内でデータ項目を区切るのに使用する文字)。
エクスポートされるデータのエンコード。たとえば、ISO-8859-1 を選択するとデータはそのコード ページを使用してエクスポートされます。エンコードの選択は、このユーティリティが実行されているマシンから取得されます。
列名をエクスポートされるデータの先頭行として出力するかどうか。
データベース テーブルからデータをエクスポートするには
1 特定のデータベースの場合、テーブル ノードの下位にあるテーブル名を右クリックします。
システム テーブルに関心がある場合は、システム オブジェクトの下位にあるテーブルを展開します。
2 データのエクスポート]をクリックします。
3 上で述べたエクスポート特性を指定し、[終了]をクリックします。
ストアド プロシージャ、トリガー、ユーザー定義関数、およびビュー
PCC では、ストアド プロシージャ、トリガー、ユーザー定義関数、およびビューを作成する CREATE スクリプトを管理できます。PSQL エクスプローラーでは、これらの項目は各データベースのフォルダー内に表示されます。
項目
オペレーションのレベル
説明
関連情報
ストアド プロシージャ
データベース
1 つまたは複数の SQL ステートメントの集合で、ユーザー指定のパラメーターを受け付けて返します。
SQL Engine Reference』の CREATE PROCEDURE
 
トリガー
テーブル
ストアド プロシージャの一種で、INSERT、UPDATE、または DELETE によってテーブルが変更されたときに自動的に実行されます。
SQL Engine Reference』の CREATE TRIGGER
 
ユーザー定義関数
データベース
値を返すスカラー ルーチンです。
SQL Engine Reference』の CREATE FUNCTION
 
ビュー
データベース
クエリから作成され、テーブルのように動作するデータベース オブジェクトです。
SQL Engine Reference』の ALTER GROUP
 
これらの機能を使用するかどうかは任意ですが、上級のデータベース ユーザーにとっては興味深いかもしれません。
グループ、ユーザー、およびセキュリティ
セキュリティは、ユーザーがデータベースにアクセスするためにユーザー名とパスワードを指定することを要求するデータベース プロパティです。デフォルトで、データベース セキュリティは無効になっています。
データベース セキュリティは PCC を使用するか SQL ステートメントを実行して無効にすることができます。有効にしたら、グループおよびユーザーを作成して権限を与えることができます。権限は、「データベース」、「テーブル」、「列」の 3 つのレベルでアクセス権を指定できます。
セキュリティの設定を有効または無効にするときは、その時点で、Master ユーザーが接続を 1 つだけ開き、かつ接続している唯一のユーザーでなければなりません。セキュリティを最初に有効に設定した直後には、Master ユーザーのみがデータベースにアクセスできます。Master ユーザー パスワードでは、PSQL のすべてのパスワードと同様に大文字と小文字が区別されます。
注意: セキュリティをオンにしたら、パスワードを有効な長さで指定してください。パスワード フィールドを空白のままにしないでください。データベースが重大なセキュリティの危険にさらされます。
セキュリティ モードの詳細については、『Advanced Operations Guide』の PSQL セキュリティを参照してください。
セキュリティの作業
このセクションでは、PSQL セキュリティのさまざまな管理作業の手順を説明します。次の表では、管理作業をカテゴリ別に示しています。
カテゴリ
説明
セキュリティの使用法全般の説明
MicroKernel エンジンへのセキュリティ ポリシーの適用
ユーザーおよびグループの作成
ユーザーおよびグループへの権限の適用
暗号化作業
データ暗号化の適用
Advanced Operations Guide』のデータの暗号化を参照してください。
一般的な作業
データベースからログアウトおよびデータベースへログインするには
1 PCC PSQL エクスプローラーでデータベース名を右クリックし、次に、ログアウト名前)をクリックします。
名前は、現在データベースにログインしているユーザーの名前を反映します。データベースでセキュリティが有効にされていない場合、名前Master です。現在のユーザーが Master としてログインしている場合は、名前も Master です。
そのデータベースで展開されていたノードは折りたたまれます。
2 データベース名を右クリックして[ログイン]を選択します。
3 ユーザー名とパスワードを入力し、[OK]をクリックします。
メモ: Master ユーザーの場合、別のユーザーとしてログインすると、当該ユーザーに割り当てられている権限がもっと制限された状況をテストするのに役立ちます。
PSQL エクスプローラーを使ってセキュリティを有効にするには
データベースがリモート マシンにある場合は、管理者のユーザー名とパスワード、またはリモート マシンの Pervasive_Admin グループのメンバーのユーザー名とパスワードを提供する必要があります。ログインしているローカル マシンにデータベースがある場合(かつ、ローカル マシンでターミナル サービスが実行されていない場合)は、ユーザー名とパスワードは必要ありません。
セキュリティを有効にすると、すべてのユーザーは、データベースの有効なユーザー名とパスワードを使ってログインしない限り、データベースにアクセスできないようになります。セキュリティを有効にするまでユーザー名とパスワードは設定できないため、そのユーザーのユーザー アカウントが設定されるまでの期間、各ユーザーはデータベースにアクセス不能となります。
1 PSQL エクスプローラーで、まずエンジン ノードを、次にデータベース ノードを展開します。
2 目的のデータベースを右クリックし、[プロパティ]をクリックします。
3 セキュリティ]をクリックします。
4 セキュリティ]タブで、セキュリティの[有効]オプションを選択します。
5 Master パスワード]にパスワードを入力し、[パスワードの確認]にもう一度同じパスワードを入力します。
6 OK]をクリックします。
これで、データベース セキュリティがオンになり、Master ユーザーとしてログインされます。データベース ユーザーのアカウントの作成に関する説明については、ユーザーとグループの作業を参照してください。
SQL を使ってセキュリティを有効にするには
管理者として、もしくは Pervasive_Admin オペレーティング システム セキュリティ グループのメンバーとしてコンピューターにログインしている必要があります。
セキュリティを有効にすると、すべてのユーザーは、データベースの有効なユーザー名とパスワードを使ってログインしない限り、データベースにアクセスできないようになります。セキュリティを有効にするまでユーザー名とパスワードは設定できないため、そのユーザーのユーザー アカウントが設定されるまでの期間、各ユーザーはデータベースにアクセス不能となります。
1 一般的な作業の説明に従って、データベースのセキュリティを有効にします。
2 PCC の[ファイル]メニューで、[新規作成]>[SQL ドキュメント]をクリックします(または、ツールバーの をクリックします)。
データベースの選択]ダイアログ ボックスが表示されます。
3 リストで、グループまたはユーザーを作成するデータベースをクリックします。
4 OK]をクリックします。
5 SQL Editor で、SQL ステートメントの SET SECURITY = 'password' を発行します。ここで password は Master ユーザーのパスワードとして使用するテキスト文字列です。
6 SQL]>[テキストに実行]をクリックします(または、ツールバーの をクリックします)。
SQL Engine Reference』の SET SECURITY も参照してください。
PSQL エクスプローラーを使用してセキュリティを無効にするには
管理者として、もしくは Pervasive_Admin オペレーティング システム セキュリティ グループのメンバーとしてコンピューターにログインしている必要があります。
注意: セキュリティをオフにすると、データベース セキュリティが混合モードまたはデータベース モードである場合は、すべてのオペレーティング システム ユーザーが、データベースにアクセスできるようになります。セキュリティを無効にしてもデータベースのユーザー名、パスワード、および権限は保持されていますが、使用されません。セキュリティを再度有効にすると、以前のユーザー名、パスワード、および権限が再び有効になります(Master ユーザーは例外です。Master パスワードは保持されず、再度適用もされません)。
1 PSQL エクスプローラーで、まずエンジン ノードを、次にデータベース ノードを展開します。
2 目的のデータベースを右クリックし、[プロパティ]をクリックします。
3 セキュリティ]をクリックします。
4 データベース セキュリティ]タブをクリックします。
5 無効]オプションをクリックします。
6 OK]をクリックします。
これで、データベース セキュリティはオフになりました。
SQL を使ってセキュリティをオフにするには
注意: セキュリティをオフにすると、データベース セキュリティが混合モードまたはデータベース モードである場合は、すべてのオペレーティング システム ユーザーが、データベースにアクセスできるようになります。セキュリティを無効にしてもデータベースのユーザー名、パスワード、および権限は保持されていますが、使用されません。セキュリティを再度有効にすると、以前のユーザー名、パスワード、および権限が再び有効になります(Master ユーザーは例外です。Master パスワードは保持されず、再度適用もされません)。
1 一般的な作業の説明に従って、データベースのセキュリティを有効にします。
2 PCC の[ファイル]メニューで、[新規作成]>[SQL ドキュメント]をクリックします(または、ツールバーの をクリックします)。
データベースの選択]ダイアログが表示されます。
3 リストで、グループまたはユーザーを作成するデータベースをクリックします。
4 OK]をクリックします。
5 SQL Editor で、SQL ステートメントの SET SECURITY = NULL を発行します。
6 SQL]>[テキストに実行]をクリックします(または、ツールバーの をクリックします)。
SQL Engine Reference』の SET SECURITY も参照してください。
Btrieve セキュリティ ポリシーの作業
データベースのセキュリティ ポリシーを設定または変更するには
注意: データベースのセキュリティ ポリシーを変更することによって、現在のユーザーがデータベースにアクセスできなくなることがあります。たとえば、セキュリティを有効にしたとき、新しいセキュリティ ポリシー下では、当該ユーザーが同等のユーザー アカウントおよび権限を持たないような場合です。
1 一般的な作業の説明に従って、データベースのセキュリティを有効にします。
2 PSQL エクスプローラーで、まずエンジン ノードを、次にデータベース ノードを展開します。
3 目的のデータベースを右クリックし、[プロパティ]をクリックします。
4 セキュリティ]をクリックします。
5 Btrieve セキュリティ]タブをクリックします。
6 クラシック]、[混合]、または[データベース]の中から希望のポリシーをクリックします。
7 OK]をクリックします。
これらのセキュリティ ポリシーの詳細については、『Advanced Operations Guide』の PSQL セキュリティを参照してください。
注意: データベースのセキュリティを有効にしている場合、セキュリティ ポリシーを「クラシック」から「混合」または「データベース」に変更すると、すべてのユーザーに対しデータベース ユーザーのアカウントの作成およびその権限を作成するまで、ユーザーはデータベースにアクセスできなくなります。
定義済みの DefaultDB も含め、既存のデータベースを PSQL ファイルと使用するには
1 PSQL エクスプローラーで、まずエンジン ノードを、次にデータベース ノードを展開します。
2 目的のデータベースを右クリックし、[プロパティ]をクリックします。
3 ディレクトリ ノードを選択し、[新規]ボタンをクリックします。
4 PSQL ファイルのパスを入力したら、[OK]をクリックします。
ファイルが複数のディレクトリに散在している場合は、ファイルすべてに共通の上位ディレクトリを指定します。必要であればルート レベルを指定することもできますが、そうすると、ルート レベルとその下位ディレクトリにあるすべての PSQL ファイルがデータベースに含まれてしまいます。
すべてのディレクトリを入力する必要はありません。データベースに含める Btrieve ファイルすべてに共通する最下位のディレクトリのみ入力します。
5 一般的な作業の説明に従って、データベースのセキュリティを有効にします。
6 ユーザーとグループの作業の説明に従って、ユーザーおよびグループの権限を設定します。
ユーザーとグループの作業
PSQL エクスプローラーを使って新しいグループを作成するには
グループを別のグループに追加することはできません。
1 一般的な作業の説明に従って、データベースのセキュリティを有効にします。
2 データベース ノードを展開します。
3 グループ]を右クリックして、[新規作成]>[グループ]を選択します。
4 グループ名を入力します。
5 完了]をクリックします。
PSQL エクスプローラーを使って新しいユーザーを作成するには
以下の手順は、ローカルのデータベース セキュリティ モデルを使用する場合にのみ適用されます。Windows ドメイン セキュリティ モデルでは、ネットワーク ドメイン アカウントは PSQL データベースへのログインに使用されます。グループ メンバーシップはネットワーク管理者によって割り当てられます。PSQL は Windows ネットワーク認証サーバーに照会してユーザーの資格情報を確認し、権限が定義されている PSQL グループのメンバーシップを検索して一致させます。
1 一般的な作業の説明に従って、データベースのセキュリティを有効にします。
2 データベース ノードを展開します。
3 ユーザー ノードを右クリックし、[新規作成]>[ユーザー]をクリックします。
4 ユーザー名を入力します。
5 パスワードを入力します。
パスワードでは大文字小文字が区別されます。データベース オブジェクトの長さと無効な文字の一覧については、『Advanced Operations Guide』の識別子の種類別の制限を参照してください。
6 任意で、ユーザーをグループに割り当てます。
グループ]の をクリックし、一覧の中から目的のグループをクリックします。
7 完了]をクリックします。
PSQL エクスプローラーを使用してユーザーをグループに割り当てるには
ユーザーは、1 つのグループのみのメンバーになることができます。グループ内のすべてのユーザーは、そのグループに定義された権限と同じ権限を持ちます。ユーザーがグループに参加すると、そのユーザーの個人用のユーザー権限は無視され、所属するグループのアクセス権と PUBLIC アクセス権を組み合わせた権限が適用されます。グループに存在するユーザーに個別に権限を許可したり取り消したりすることはできません。
1 一般的な作業の説明に従って、データベースのセキュリティを有効にします。
2 目的のグループが存在しない場合は、PSQL エクスプローラーを使って新しいグループを作成するにはの説明に従ってグループを作成します。
3 ユーザー ノードの下にあるユーザー名を右クリックし、[プロパティ]をクリックします。
4 全般の設定]をクリックします。
5 グループ]の をクリックし、一覧の中から目的のグループをクリックします。
6 OK]をクリックします。
PSQL エクスプローラーを使用してユーザーまたはグループを削除するには
グループは、ユーザーが割り当てられていない場合のみ削除することができます。
1 データベース ノードを展開します。
2 グループ ノードまたはユーザー ノードを展開します。
3 目的のグループまたはユーザー名を右クリックします。
4 削除]をクリックします。
5 はい]をクリックします。
SQL を使用してグループおよびユーザーの作業を行うには
1 一般的な作業の説明に従って、データベースのセキュリティを有効にします。
2 PCC の[ファイル]メニューで、[新規作成]>[SQL ドキュメント]をクリックします(または、ツールバーの をクリックします)。
データベースの選択]ダイアログ ボックスが表示されます。
3 リストで、グループまたはユーザーを作成するデータベースをクリックし、[OK]をクリックします。
4 SQL Editor で、グループまたはユーザーのために必要なステートメントを作成します。
SQL ステートメントの詳細については、『SQL Engine Reference』で以下のステートメントを参照してください。
CREATE GROUP
ALTER GROUP
DROP GROUP
CREATE USER
ALTER USER
DROP USER
GRANT
REVOKE
SET PASSWORD
5 ステートメントを実行するには[SQL]>[テキストに実行]をクリックします(または、ツールバーの をクリックします)。
メモ: Windows ドメイン認証を使用して PSQL データベースを保護している場合、Active Directory で、データベース ユーザーが含まれるグループを削除すると、そのユーザーはデータベースにログインできなくなります。ユーザーのログイン資格を復元するには、Active Directory で使用していた同じ名前で PSQL グループを再作成してください。
権限の割り当て作業
ここで説明するすべての作業に関して、オブジェクトに権限を割り当てるときに、使用する Btrieve ファイルにオーナーネームがある場合は、まず、そのオーナー ネームを GRANT または SET OWNER ステートメントを使用して指定しなければなりません。詳細については、『SQL Engine Reference』を参照してください。
PSQL エクスプローラーを使用してグループに権限を割り当てるには
メモ: データベース]タブの権限は、[テーブル]タブの権限を無効にします。
1 目的のデータベース ノードを展開します。
2 グループ ノードの下にあるグループ名を右クリックし、[プロパティ]をクリックします。
3 権限]をクリックします。
4 データベースまたはテーブルの列用の権限、また V2 メタデータ、ストアド プロシージャ、ビュー用の権限を設定できるタブをクリックします。『SQL Engine Reference』のビューおよびストアド プロシージャに対する権限も参照してください。
5 このタブで、必要な権限を設定します。
チェック マークは、その権限が適用されることを示します。
6 OK]をクリックします。
PSQL エクスプローラーを使用してユーザーに権限を割り当てるには
メモ: ユーザーがグループのメンバーである場合、そのユーザーに特定の権限を割り当てることはできません。そのユーザーには、グループの権限と PUBLIC グループの権限を組み合わせたものが適用されます。[データベース]タブの権限は、[テーブル]タブの権限を無効にします。
1 目的のデータベース ノードを展開します。
2 ユーザー ノードの下にあるユーザー名を右クリックし、[プロパティ]をクリックします。
3 権限]をクリックします。
4 データベースまたはテーブルの列用の権限、また V2 メタデータ、ストアド プロシージャ、ビュー用の権限を設定できるタブをクリックします。『SQL Engine Reference』のビューおよびストアド プロシージャに対する権限も参照してください。
5 このタブで、必要な権限を設定します。
チェック マークは、その権限が適用されることを示します。
6 OK]をクリックします。
PSQL エクスプローラーを使用してすべてのユーザーに権限を割り当てるには
メモ: データベース]タブの権限は、[テーブル]タブの権限を無効にします。
1 目的のデータベース ノードを展開します。
2 グループ ノードの下にある PUBLIC を右クリックし、[プロパティ]をクリックします。
3 権限]をクリックします。
4 データベース、テーブル、およびそのテーブルの列、また V2 メタデータ、ストアド プロシージャやビュー用のさまざまな権限を設定できるタブをクリックします。『SQL Engine Reference』のビューおよびストアド プロシージャに対する権限も参照してください。
5 そのタブで、目的の権限のオプションをクリックします。
チェック マークは、その権限が適用されることを示します。
6 OK]をクリックします。
SQL を使用してグループまたはユーザーに権限を割り当てるには
1 PCC の[ファイル]メニューで、[新規作成]>[SQL ドキュメント]をクリックします(または、ツールバーの をクリックします)。
データベースの選択]ダイアログ ボックスが表示されます。
2 目的のデータベース ノードを展開し、[OK]をクリックします。
3 SQL Editor で、グループまたはユーザーのために必要なステートメントを作成します。
SQL Engine Reference』で、以下のトピックを参照してください。
GRANT
REVOKE
SET PASSWORD
4 SQL]>[テキストに実行]をクリックします(または、ツールバーの をクリックします)。
データベース エンジンとクライアントの設定
ほとんどのユーザーの一般的なニーズは、インストール中にデフォルトで行われる PSQL サーバーまたはそのクライアントの設定で満たされます。ただし、デバッグ、メモリ使用量、パフォーマンス チューニングなど特定の目的のために、設定を変更しなければならない場合もあります。このような設定は、PSQL ではプロパティと呼ばれています。プロパティを管理するには、PCC やコマンド ラインを使用します。
エンジンとクライアントのプロパティの参照先については、『Advanced Operations Guide』に記載された以下のトピックをご覧ください。
PCC でエンジンのプロパティを設定するには
PCC でローカル クライアントのプロパティを設定するには
サーバーとクライアントの設定の詳細については、『Advanced Operations Guide』の以下のトピックを参照してください。
サービス設定プロパティ
全プラットフォームにおけるサーバー設定プロパティ
Windows クライアント設定プロパティ
Linux および OS X クライアント設定プロパティ
[ファイルを開く]ダイアログと[ファイルを保存]ダイアログ
PCC では、ファイルを開く場合やファイルを保存(別名保存も含む)する場合に、デフォルトで独自のダイアログを使用します。PCC が扱うファイルは SQL ドキュメント ファイルであるため、2 つのダイアログにはそれぞれ[SQL ドキュメントを開く]および[SQL ドキュメントの保存]というタイトルが付けられています。したがって、[ファイル]>[新規作成]を選択すると、SQL ドキュメントが作成されます。
このダイアログを使用すると、システム エンコードとは異なる文字エンコードのファイルを使用する作業が、ファイルを開く/保存用の標準ダイアログで行うよりも簡単になります。たとえば、ワイド文字データを含む SQL スクリプトを作成し、適切なエンコードを指定しないで保存した場合は、データが失われることもあります。この例の場合、使用中のシステム コード ページが ワイド文字 をサポートしないことが考えられます。
ここでは、以下の項目について説明します。
エンコードの選択
デフォルトのエンコード
ファイル名で使用できない文字
ファイルを開くダイアログ([SQL ドキュメントを開く])
ファイルを保存するダイアログ([SQL ドキュメントの保存])
オペレーティング システムの標準ダイアログを使用する
エンコードの選択
このダイアログでは、ファイルを開く/保存するときのエンコードを変更することができます。さらに、ファイルを開く([SQL ドキュメントを開く])ダイアログでは、選択したファイル エンコードに基づき、データのプレビューを表示します。次の表では選択できるエンコードについて説明します。
 
表 11 ファイルを開く/保存用ダイアログで選択できるエンコード
エンコード
説明
(システム コード ページ)
デフォルトは、現在使用しているシステム コード ページです。たとえば、Windows の英語版プラットフォームの場合は、一般的に "Windows-1252" が設定されています。
Big5
Big5 は繁体字中国語の文字エンコードで、中国語の中でもっとも一般的に使われています。
EUC_JP
EUC(Extended Unix Code)_JP は可変幅の文字エンコードで、日本語文字の 3 つの標準セットである IS X 0208(基本漢字)、JIS X 0212(補助漢字)、そして JIS X 0201(半角カナ)の要素を表すのに使用します。
Shift_JIS
Shift_JIS(Japan Industrial Standards)は日本語の文字エンコードです。
UTF-8
UTF(Universal Character Set Transformation Format)-8 は 8 ビットの可変幅の文字エンコードで、Unicode 文字セットですべての文字を表すことができます。このエンコードは ASCII との下位互換性があり、エンディアンや BOM(Byte Order Mark:バイト オーダー マーク)が回避できるよう設計されています。
UTF-8 with BOM(BOM 付き UTF-8)
UTF-8 と同様ですが、こちらは BOM(バイト オーダー マーク)が付きます。この BOM は、エンディアン(バイト順)を示すのに使用する Unicode 制御文字で、ファイルを保存するときに付けられます。
UTF-16BE(ビッグ エンディアン)
16 ビットの UTF エンコードで、ビッグ エンディアン(BE)のバイト オーダーが使われます。
UTF-16BE with BOM(BOM 付き UTF-16BE)
UTF-16BE と同様ですが、こちらは BOM(バイト オーダー マーク)が付きます。BOM はファイルを保存するときに付けられます。
UTF-16LE(リトル エンディアン)
16 ビットの UTF エンコードで、リトル エンディアン(LE)のバイト オーダーが使われます。
UTF-16LE with BOM(BOM 付き UTF-16LE)
UTF-16LE と同様ですが、こちらは BOM(バイト オーダー マーク)が付きます。BOM はファイルを保存するときに付けられます。
メモ:
デフォルトで、PCC は一度開かれたファイルのエンコード形式を記憶します。ファイルを編集し、上書き保存する場合、その編集内容は元の(記憶した)エンコードで保存されます。しかし、PCC の[別名保存]ダイアログを使用すれば、エンコードを指定して編集内容を保存することができます。
ファイルが BOM 付きの場合は、PCC が自動的にエンコード方法を検出し、ファイルを選択して開くダイアログ([ファイル]メニューの[開く])にそのエンコードを表示します。BOM が付いてないファイルで、バイト オーダーが重要になる場合は、ファイルを保存するときに適切なエンコードを選択する必要があります。
デフォルトのエンコード
ファイルを開く/保存するときにファイルのエンコードを変更できるのに加え、これらの作業時にデフォルトで使用するエンコードを設定することもできます。データのインポート/エクスポート、およびスキーマのエクスポートに対し、このデフォルトのエンコードが共通に使用されます。データ インポート ウィザードを使ったデータのインポートデータ エクスポート ウィザードを使ったデータのエクスポート、およびスキーマの管理を参照してください。たとえば、ファイルを開く場合とファイルを保存する場合で、異なるエンコードをデフォルトとして設定することはできません。
ファイルを開く/保存する場合のデフォルト エンコードを設定するには
1 PCC で、[ウィンドウ]>[設定]>[PSQL]>[ファイル エンコード]を選択します。
2 [デフォルト エンコード]ドロップダウン リストから、エンコードを選択します。
選択できるエンコードの詳細については、ファイルを開く/保存用ダイアログで選択できるエンコードを参照してください。
3 OK]をクリックします。
メモ: このファイル エンコードの初期設定には、ファイルを開く/保存、データのインポート/エクスポート、スキーマのエクスポート、テーブル スキーマのエクスポートの各ダイアログからでもアクセスできます。ダイアログ内の[デフォルトのエンコードを変更する]リンクをクリックしてください。
ファイル名で使用できない文字
ファイルを開く/保存する前に、それぞれのダイアログではファイル名で使用している文字が有効かどうかを確認します。ファイル名に利用できない文字には、/ : * ? \ " < > | があります。
ファイルを Windows と Linux、または Windows と OS X で使用する場合、これらの文字は PSQL でサポートされているどのオペレーティング システムでも使用できません。
ファイルを開くダイアログ([SQL ドキュメントを開く])
次の図は、PSQL で提供されるサンプル ファイル demodata.sql を選択しようとしているダイアログ ウィンドウです。プレビューには、このファイルの冒頭の数行が表示されます。
[ドキュメント]フィールドには、前回のファイルを開く/保存操作で使用したディレクトリがデフォルトで表示されます。ほかのファイルや場所を選択するには[参照]ボタンを使用します。
ファイルを保存するダイアログ([SQL ドキュメントの保存])
次の図はファイルの保存用ダイアログを表しています。プレビューは適用されません。[ドキュメント]フィールドには、前回のファイルを保存/開く操作で使用した場所がデフォルトで表示されます。
SQL ドキュメントを保存する場合は、完全なパスとファイル名が必要です。[参照]ボタンをクリックすると、オペレーティング システムの標準のファイル参照ダイアログが表示されます。
オペレーティング システムの標準ダイアログを使用する
ファイルを開く/保存に、オペレーティング システムの標準ダイアログを使用することもできます。たとえば、システム コード ページ以外のエンコードを使って作業する必要がない場合には、標準のダイアログを利用することもできます。
ファイルを開く/保存する場合にオペレーティング システムの標準のダイアログを利用するには
1 PCC で、[ウィンドウ]>[設定]>[PSQL]>[ファイル エンコード]を選択します。
2 [ファイルを開く]および[ファイルを保存]時にエンコードのプロンプトを表示しない]オプションを選択します。
3 OK]をクリックします。
メモ: このファイル エンコードの初期設定には、ファイルを開く/保存、データのインポート/エクスポート、スキーマのエクスポートの各ダイアログからでもアクセスできます。ダイアログ内の[デフォルトのエンコードを変更する]リンクをクリックしてください。
データのインポート/エクスポート、スキーマのエクスポートでサポートされるワイド文字データ
データのインポート/エクスポート、スキーマのエクスポートで、ワイド文字データを含むファイルを扱えるようになりました。ファイルを開く/保存する場合と同じく、ファイルのインポート/エクスポート時にエンコードを変更することができます。エンコードの選択を参照してください。
このダイアログでファイルのパスと名前を入力するフィールドには、前回データをインポート/エクスポートまたはスキーマをエクスポートしたときに使用した場所がデフォルトで表示されます(データのインポート/エクスポート、スキーマのエクスポートは一貫した設定を利用します)。ファイルをインポート/エクスポートする場合は、絶対パス名が必要です。
[ファイルを開く]ダイアログと[ファイルを保存]ダイアログも参照してください。
[データのインポート]ダイアログ
[データのインポート]では、ファイルのエンコードの変更や、デフォルトのエンコード設定が可能になりました。さらに、[プレビュー]領域では、選択したファイル名、ファイル エンコード、およびその他のオプションに基づくデータのプレビューを表示します。たとえば、次の図は、PSQL で提供する class.sdf テーブルをインポートしようとしている画面です。[エンコード]フィールドには "windows-31j" が設定されています。[プレビュー]領域には、設定したエンコードで、区切り文字が "カンマ"、先頭行に列名が含まれていない([先頭行に列名が含まれている]オプションがオフ)場合に、ファイルのデータがどのように見えるかを表示しています。
BOM 付きのファイルをインポートする場合、BOM はインポート時に認識され、取り除かれます。また、このダイアログ内でどのエンコードを選んでも、ファイルは BOM で指定されているエンコードでインポートされます。つまり、BOM が[エンコード](オプション)での選択を無効にするということです。
参照]ボタンをクリックすれば、オペレーティング システムの標準ダイアログを利用することができます。
データ インポート ウィザードを使ったデータのインポートも参照してください。
[データのエクスポート]ダイアログ
[データのエクスポート]では、ファイルのエンコードの変更や、デフォルトのエンコード設定が可能になりました。[例:]フィールドには、プレビューでなく、選択したオプションによる例が表示されていることに注意してください。
次の図は、DEMODETA サンプル データベースに含まれる Course テーブルのデータをエクスポートするための設定例です。[先頭行に列名を書き込む]オプションが選択され、[区切り文字]は "コロン" が設定されています。
エクスポート操作では、CHAR データ型と NCHAR データ型の値の末尾の空白が削除されることに注意してください。[参照]ボタンをクリックすることで、オペレーティング システムの標準のファイル参照ダイアログが表示できます。
データ エクスポート ウィザードを使ったデータのエクスポートも参照してください。
[スキーマのエクスポート]ダイアログ
テーブル スキーマのエクスポートで、ファイルのエンコードの変更や、デフォルトのエンコードの変更が可能になりました[例:]フィールドには、プレビューでなく、選択したオプションによる例が表示されていることに注意してください。
次の図は、DEMODETA サンプル データベースに含まれる Faculty テーブルのスキーマをエクスポートするための設定例です。['IN DICTIONARY' 句を CREATE ステートメントに追加する]オプションが選択され、[例:]領域に IN DICTIONARY 句が含まれていることに留意してください。
データベース スキーマのエクスポート ウィザードには、類似の設定はありますが、[例:]フィールドはありません。すべてのテーブルをエクスポートする必要があるためです。詳細については、スキーマの管理を参照してください。