基本的なトラブルシューティング
一般的な問題の識別と解決方法
この章では、トラブルシューティングおよび一般的に最も多く発生する問題を解決するための情報を提供します。
Pervasive PSQL メッセージ ログ
Pervasive PSQL ではメッセージ用のさまざまなログ リポジトリを提供して、トラブルシューティングを支援します。ログは大きく分けて 2 つのカテゴリに分類されます。
•すべてのメッセージ：これらのメッセージにはステータス、エラー、警告および情報メッセージが含まれます。これらは、ライセンス管理コンポーネントを含め、あらゆる Pervasive PSQL コンポーネントから発生します。
•ライセンス メッセージ：これらのメッセージは、ライセンスに関する問題を警告し、そのトラブルシューティング情報を提供します。これらはライセンス管理コンポーネントから発生します。
次の表にログ リポジトリの概要を示します。
表 20 Pervasive PSQL メッセージ ログ リポジトリ
リポジトリ | 記録元 |
| ライセンス管理コンポーネント |
| ライセンス管理コンポーネント（Windows） Pervasive PSQL の全コンポーネント（Linux） |
| Pervasive PSQL の全コンポーネント（Windows） |
ライセンス メッセージ
ログ リポジトリのいくつかはライセンス メッセージに重点を置いています。これは、Pervasive PSQL のライセンス コンポーネントが、データベース エンジン用のキーの有効性を定期的に検証するからです。キーが無効と判定されると、そのキーの状態は "アクティブ" から "検証失敗" に変わります。この状態でも一定の期間内はデータベース エンジンが正常に機能するので、検証失敗を修正するための時間は十分にあります。
この期間が終わる前に検証失敗を修正しなかった場合は、キーの状態が "無効" に変わります。これにより、このキーは無効となりデータベース エンジンはデータ ファイルにアクセスできなくなります
検証失敗への対応を適時に行う必要があるため、キーの状態の変更はできるだけ早く通知されるようになっています。たとえば、1 つのメッセージがすべてのメッセージ リポジトリに記録されます。リポジトリの中で最もわかりやすいのは Pervasive Notification Viewer です。（License Administrator でもキーの状態が表示されます。このため、いつでも検証動作を実行して状態を再確認することができます。『
Pervasive PSQL User's Guide』の
ライセンス管理を参照してください）。
キーの状態の変更
次の表では、キーの状態の変更に応じて返されるメッセージのタイプについて説明します。
表 21 キーの状態の変更に応じたメッセージのタイプ
メッセージのタイプ | キーの状態の変更 | シナリオ |
| 変更前 | 変更後 | |
警告 | アクティブ | 検証失敗 | 検証動作によってキーの検証失敗が検出されました。たとえば、マシン署名を判別できないためキーと一致しなくなった、または 1 つまたは複数のライセンス コンポーネントをロードできないなどが原因です。 この状態でも一定の期間内はデータベース エンジンが正常に機能するので、検証失敗を修正するための時間は十分にあります。 |
警告 | 無効 | 検証失敗 | キーが無効になった原因のいくつかは修正されていますが、まだ解決する必要がある問題が少なくとも 1 つあります。 キーの状態は検証失敗に変わったため、一定の期間内はデータベース エンジンが正常に機能するので、検証失敗の原因を修正することができます。 |
エラー | 検証失敗 | 無効 | 検証失敗の原因を修正するために提供された期間が過ぎました。検証失敗の原因となる状態が期限内に修正されませんでした。キーは無効になり、データベース エンジンはデータ ファイルにアクセスきません。 |
情報 | 検証失敗 | アクティブ | 検証失敗となった原因が修正されています。キーは有効になり、データベース エンジンはすべて機能します。 |
情報 | 無効 | アクティブ | キーが無効になった原因が修正されました。キーは有効になり、データベース エンジンはすべて機能します。 |
状態が "期限切れ"（一時キーの場合のみ適用）、または "非アクティブ"（前バージョンの Pervasive PSQL で登録されたままのキーに適用）となっているキーに関するメッセージは記録されないので注意してください。
ログ記録の頻度
次の表は、ライセンス メッセージが記録される頻度を特定の動作別に示しています。
表 22 メッセージのログ記録の頻度（起因動作別）
起因動作 | ログ記録の頻度 | ログ リポジトリ1 |
| 即時 | •Pervasive Notification Viewer •オペレーティング システムのイベント ログ •Pervasive PSQL のイベント ログ |
キーが検証失敗状態のまま | 1 日 1 回通知 | •Pervasive Notification Viewer •オペレーティング システムのイベント ログ •Pervasive PSQL のイベント ログ |
API 呼び出しによってプログラムから起動した検証動作 『 Pervasive PSQL User's Guide』の 認証残り回数を表示するには、『 Distributed Tuning Interface Guide』の PvValidateLicenses()、および『 Distributed Tuning Objects Guide』の ValidateLicenses を参照してください。 | 即時 | •オペレーティング システムのイベント ログ •Pervasive PSQL のイベント ログ |
Pervasive PSQL ライセンス サーバーから発生した警告またはエラー メッセージ | 即時 | •オペレーティング システムのイベント ログ •Pervasive PSQL のイベント ログ |
1メッセージ ログは一方向の階層に従って記録されます。Pervasive Notification Viewer へ記録されるライセンス メッセージはオペレーティング システムのイベント ログへ、さらに Pervasive PSQL イベント ログへと記録されます。オペレーティング システムのイベント ログに記録されるライセンス メッセージは、Pervasive PSQL イベント ログにも記録されます。 |
Pervasive Notification Viewer
Pervasive Notification Viewer（以下「Notification Viewer」）は、ライセンス コンポーネントによって記録されるメッセージを表示するアプリケーション ユーティリティです。このユーティリティは、注目すべきライセンス メッセージ（表
22 を参照）をわかりやすく通知することを目的としています。
Notification Viewer は、デフォルトで Pervasive PSQL Server（Windows および Linux バージョンの 32 ビットおよび 64 ビット版）および Pervasive PSQL Workgroup のインストール時に一緒にインストールされます。また、Windows プラットフォームではデフォルトで、Windows を再起動すると Notification Viewer も再起動します。
Windows プラットフォームの場合、この実行可能ファイルの名前は notifyviewer.exe です。 このユーティリティはユーザーに対し、単独で実行するインスタンスを提供します。Notification Viewer が既に実行されている状態で新たに Notification Viewer を起動しようとすると、実行済みの GUI が画面の最前面に表示されます。
Linux ディストリビューションの場合、このユーティリティは notifyviewer という名前のシェル スクリプトです。このシェル スクリプトは実行するたびに、新たな Notification Viewer インストタンスを起動します。Linux を再起動した場合は、Notification Viewer を手動で再起動する必要があります。Linux の再起動時、このシェル スクリプトは自動的には実行されません。
コマンド ライン オプション
次のコマンドライン オプションを使用すると、このユーティリティの実行方法を指定できます。
オプション | 説明 |
（オプションなし） | オプションを指定しないでこのユーティリティを実行する場合は、GUI が表示され、オペレーティング システムがシステム トレイをサポートしている場合はトレイ アイコンが現れます。 |
-tray | このオプションを指定してユーティリティを実行すると、GUI が表示されずトレイ アイコンを表示します。オペレーティング システムでシステム トレイがサポートされない場合は、GUI が表示されます。 |
Notification Viewer では、システム トレイ アイコンとグラフィカル ユーザー インターフェイス（GUI）の 2 つのインターフェイスを提供します。
システム トレイ アイコン インターフェイス
デフォルトで、Windows の場合は、Notification Viewer を実行すると GUI は表示されずトレイ アイコンが表示されます（Linux の場合、Notification Viewer は GUI として実行し、その Linux ディストリビューションがシステム トレイをサポートしている場合は、システム トレイ アイコンを表示します）。ユーティリティが実行されると、ライセンス メッセージの監視を開始します。
Notification Viewer が未読のメッセージを検出すると、トレイ アイコンは未読メッセージを示す表示に変わります。
トレイ アイコンを参照してください。
Notification Viewer は 2 種類のツールヒントも表示します。ツールヒントをマウスでポイントすると、重要な未読メッセージがある場合はそのメッセージ数、未読メッセージの総数が表示されます。メッセージがすべて既読の場合はユーティリティの名前が表示されます。通知する必要があるメッセージを Notification Viewer が検出した場合は、バルーン形式のツールヒントが表示されます。Windows の場合、このツールヒントは直接閉じるか、キーボードまたはマウス操作を行わない限り表示され続けます。Linux の場合、このツールヒント上をクリックして閉じる必要があります。
ポップアップ メニュー
トレイ アイコンのポップアップ メニューには、［Pervasive Notification Viewer を開く］（GUI を開く）および［終了］（ユーティリティを終了する）があります。このポップアップ メニューはトレイ アイコンを右クリックすると表示されます。
トレイ アイコン
次の表ではトレイ アイコンの意味を説明します。
アイコン | 説明 |
| Notification Viewer は実行中でライセンス メッセージを監視しています。このアイコンは、すべてのメッセージが開封済み（既読）である "正常" な状態を示しています。 |
| Notification Viewer には未読メッセージがあります。 このアイコンは、未読メッセージがすべて開封されない限り表示され続けます。 左パネルを参照してください。 |
グラフィカル ユーザー インターフェイス
トレイ アイコンをダブルクリックするか、トレイ アイコンを右クリックして［Pervasive Notification Viewer を開く］をクリックすると Notification Viewer GUI を開くことができます。Linux の場合はデフォルトで、Notification Viewer は GUI として実行し、そのシステム トレイ アイコンが表示されます（Linux での起動動作を変更する場合は、notifyviewer シェル スクリプトに -tray オプションを 渡します）。Linux ディストリビューションでシステム トレイがサポートされない場合、Notification Viewer は GUI を表示し、システム トレイ アイコンは表示しません。その場合は、シェル スクリプトを実行して Notification Viewer を起動してください）。
この GUI が表示されると、未読メッセージが直ちに GUI へ追加されます（さらに、トレイ アイコンにツールヒントが表示され、アイコンは未読メッセージを示す表示に変わります）。
Pervasive PSQL は、通知ファイルにある記録の既読または未読状態をユーザーごとに監視します。つまり、GUI を表示している各ユーザーからはすべてのメッセージが見えますが、メッセージの既読または未読状態はユーザーごと異なるということです。
Notification Viewer の 画面を閉じるとこのユーティリティは終了します。システム トレイがサポートされる場合は、画面を閉じることで GUI が非表示になり、ユーティリティが実行中であることを示すトレイ アイコンが表示されます。
ツールバーとパネル
図
31 で示すように、Notification Viewer GUI にはツールバーと 2 つのメイン パネルがあります。
図 31 Notification Viewer の GUI
GUI 要素 | 説明 |
ツールバー | 2 つのオプションを提供します。 •［未読のみ表示］（オンとオフで表示を切り替える） •［すべて開封済みにする］ |
左パネル | スクロール可能なメッセージの一覧が含まれます。 メッセージは一番上に最新のメッセージが来るようソートされ、"今日"、"昨日から 1 週間前"、"それ以前" の 3 つのグループに分けて配置されます。各グループ ノードは展開したり閉じたりすることができます。 各メッセージには、情報のタイプを表すイメージ アイコン、タイトル文字列、日付および簡単な説明が表示されます。そのメッセージが未読の場合、テキストはすべて太字で表記されます。 メッセージを読むには、そのメッセージをクリック（選択）します。一度選択すれば、そのメッセージ テキストの書体は太字から標準に変わります。 |
右パネル | メッセージの詳細を示します。ここではそのメッセージについて詳しい説明を記載し、場合によっては問題を解決する提案事項も提供されます。 |
オペレーティング システムのイベント ログ
Pervasive PSQL のライセンス管理コンポーネントは、Windows プラットフォーム上でオペレーティング システムのイベント ログにメッセージを書き込みます。Linux ディストリビューションの場合、Pervasive PSQL の全コンポーネントがオペレーティング システムのイベント ログへメッセージを書き込みます。
Windows プラットフォームのイベント ログ
Windows オペレーティング システムでは、"アプリケーション"、"セキュリティ" または "システム" として分類されるイベントの記録方法を提供しています。Pervasive PSQL はライセンス メッセージを Windows の "アプリケーション" イベント ログのみに記録します。このメッセージは PVSW.LOG に書き込まれるライセンス メッセージのサブセットです。
ライセンス メッセージは "エラー" または "警告" として分類され記録されます。これには、キーの状態の変更に起因するメッセージのほか、警告、エラー メッセージが含まれます（表
22 を参照）。さらに、表
21 で挙げているような特定の情報メッセージも記録されます。
イベント ログの表示
Windows オペレーティング システムでは、イベント ログを表示および操作するための「イベント ビューアー」という GUI を提供しています。このユーティリティは、Windows コントロール パネルから、あるいはコマンド インターフェイスで eventvwr.msc コマンドを実行してアクセスすることができます。イベント ビューアーのインターフェイスは、Windows XP/Windows Server 2003 と Windows Vista 以上では異なっているので注意してください。
どのイベント ビューアーを使用した場合でも、Pervasive PSQL はイベントに対し以下の項目を表示します。
•日付と時刻 - イベントが発生した日付と時刻
•ソース - Pervasive SQL
•分類/カテゴリ - 製品キー
•種類/レベル - イベントのレベル：情報、警告またはエラー
•イベント ID - 1000
•ユーザー - N/A
•コンピューター - コンピューターの名前
さらに Windows Vista 以上では、［キーワード］列に "クラシック"、［ログ］列に "アプリケーション" を表示します。イベント ビューアーではさらに列が表示できるようになっていますが、Pervasive PSQL はそれらに対するデータを提供しません。
Linux ディストリビューションのイベント ログ
Linux ディストリビューションの場合は、Pervasive PSQL の全コンポーネントが Linux の標準ログ システム syslog にメッセージを書き込みます。syslog はデフォルトで /var/log/messages ディレクトリに書き込みます。SQL 接続マネージャーに限り、任意でメッセージを event.log ファイルに記録することもできます。
event.log ファイルと bti.ini
Bti.ini は Lnux ディストリビューションで使用される Pervasive PSQL 設定ファイルです。デフォルトで、このファイルは /usr/local/psql/etc ディレクトリにあります。
このファイルを使用すると、SQL 接続マネージャー用の構成を行うことができます（INI ファイルの［SQLManager］セクション）。設定の 1 つである LogEvent は、イベント ログ ファイル（event.log）に記録するイベント メッセージのタイプを決定します。デフォルトで、event.log ファイルは /usr/local/psql/bin ディレクトリにあります。
bti.ini の SQLManager セクション用の各種パラメーター | 説明 |
MgrPort | SQL 接続マネージャーで使用されるポート番号を設定します。デフォルト値は 1583 です。 |
MgrUseTransport | SQL 接続マネージャーで使用されるプロトコルの種類を設定します。これは TCP に設定する必要があります |
LogEvent=msg_type | msg_type には以下の値のいずれかを指定します（デフォルトは 1 です）。この値はイベント ログ（event.log）に記録するメッセージのタイプを示します。 •0 － 記録しない •1 － エラーのみ •2 － エラーと警告 •3 － エラー、警告および情報メッセージ •4 － エラー、警告、情報メッセージおよび connect.log |
InstallDirectory=/usr/local/psql | 接続ログ /usr/local/psql/connect.log をアクティブ化します。 |
Pervasive PSQL のイベント ログ
Windows プラットフォームの場合、Pervasive PSQL の全コンポーネントが Pervasive PSQL のイベント ログへステータス、エラー、警告および情報メッセージを書き込みます（Linux ディストリビューションの場合、Pervasive PSQL は専用のイベント ログを使用しません。その代り、Pervasive PSQL の全コンポーネントが Linux の標準ログ システム syslog にメッセージを書き込みます。
Linux ディストリビューションのイベント ログ を参照してください）。
Pervasive PSQL のイベント ログは PVSW.LOG という名前が付けられ、デフォルトで ＜アプリケーション データ ディレクトリ＞\PSQL\logs ディレクトリにあります。Windows プラットフォームでは Pervasive PSQL の全コンポーネントがこのログ ファイルに書き込みます。複数の Pervasive ベースのアプリケーションが同じマシン上で動作している場合、これらのアプリケーションは PVSW.LOG を共有します。
PVSW.LOG のフィールド
PVSW.LOG は、次の表
23 で説明されている形式のテキスト メッセージで構成されます。
表 23 PVSW.LOG のフィールド
フィールド | 内容 |
Date | yyyy/mm/dd/ 形式で表される自動日付スタンプ。 |
Time | hh:mm:ss 形式で表される自動時刻スタンプ。これらの表示形式は地域の設定に従います。 |
Component | エラーを返すコンポーネントのファイル名（拡張子なしのプレフィックスのみ）。 |
Process | コンポーネントのインスタンス ID。これは、コンポーネントのプロセス ID です。 |
Process Name | コンポーネントのパスおよび名前（最後の 15 文字に短縮）。 |
Computer Name | プロセスをホストするマシンに割り当てられた名前（最初の 15 文字に短縮）。 |
Type | 1 文字：I は情報、W は警告、E はエラーです。 |
Message | 呼び出し元のコンポーネントに関連するリソースから取得される文字列、または呼び出し元のコンポーネントから直接渡されるテキスト文字列から成るメッセージ テキスト。 メッセージ テキストには数値が含まれることもあります。この数値の形式は 10 進数または 16 進数です。16 進数と 10 進数を区別するため、16 進数値の前には "0x" 文字が付けられます。 メッセージ テキストの中には、OEM アプリケーション固有の情報（ベンダーの Web サイトへのリンクやトラブルシューティング情報など）が含まれている場合もあります。 |
エントリの後に、標準の 16 進形式のバイナリ データが続くことがあります。バイナリ データの長さには、制限がありません。
PVSW.LOG のエントリ例
以下は、PVSW.LOG に含まれるデータのタイプの例です。
Date | Time | Component | Process | Process Name |
2011/05/10 | 09:53:06 | LicenseMgr | 9048 | NTDBSMGR.EXE |
Computer Name | Type | Message |
USRegion2Svr | W | ライセンスは検証に失敗しました。 修復期限は 14 日間です。 |
一般的なトラブルシューティング
ここでは、発生した問題の原因を特定するのに役立ついくつかの基本的なトラブルシューティングの手順を提供します。このセクションでは、以下の項目について説明します。
データにアクセスしようとしたときに、1114 というエラーを受け取りました。
または
接続文字列に ServerDSN または DBQ が見つからなかったというエラー メッセージを受け取りました。
PCC では、クライアント DSN なしの接続を使用してリモート サーバー データ ソース（DSN）にアクセスできます。Microsoft Excel および Access などの多くのデスクトップ アプリケーションではこれが行えません。ローカル コンピューター上でクライアント DSN を作成し、リモート サーバー DSN を使用してサーバー上のデータにアクセスできるようにします。クライアント DSN を再作成するには、
Windows クライアントからのクライアント アクセスの設定の手順に従ってください。最初に、アクセスするサーバー上にサーバー DSN が存在していることを確認する必要があります。
エンジン コンポーネントのバージョンがクライアント コンポーネントのバージョンと異なっているというメッセージを受け取りました。
クライアントのリクエスターが初めてエンジンに接続すると、クライアントのリクエスターは内部ルーター バージョンと Btrieve Version (26) 呼び出しで返された値を比較します。クライアントのバージョンがエンジンのバージョンよりも古い場合は、"エンジンのコンポーネントのバージョンがクライアントと異なります" というメッセージ ボックスがクライアント システム上で表示され、Pervasive System Analyzer（PSA）を実行するよう提示します。同じメッセージがクライアントの PVSW.LOG ファイルのログにも記録されます。
これは警告メッセージです。この状況では、クライアントはエンジンへの接続を妨げられることはありません。ただし、Pervasive Software が互換性を保証するのは、クライアントがデータベース エンジンと同じバージョンの場合のみです。このメッセージが表示されたときに、PSA の実行を行わずに古いクライアント コンポーネントを保持し、新しいクライアントをインストールした場合は、クライアントのバージョンがエンジンのバージョンと同じになるまで、製品が予期しない動作をすることが考えられます。
メモ： Pervasive は、データベース エンジンと同じバージョンのクライアント リクエスターを使用することをお勧めします。通信するデータベース エンジンより古いバージョンのクライアント リクエスターを使用することもできます。ただし、アプリケーションで使用する SDK アクセス方法のタイプによっては、古いバージョンのリクエスターがデータベース エンジンで動作しないこともあります。アプリケーションはデータベース エンジンと通信できなくなります。そのような状況の場合は、データベース エンジンと同じバージョンのクライアント リクエスターを使用する必要があります。
データベース エンジンよりも新しいバージョンのクライアント リクエスターの場合、正しく機能するかどうかはわかりません。Pervasive では、新しいバージョンのクライアント リクエスターが古いバージョンのエンジンで正しく動作することを保証しません。このため、新しいバージョンのクライアント リクエスターと古いバージョンのエンジンを一緒に使用しないようにしてください。
サーバー エンジン上のデータを取得することができません。
サーバー エンジン上のデータを取得できないときは、ほとんどの場合以下のことが原因です。
•サーバー コンピューターがダウンしているか、またはネットワークが中断されています。
•サーバーへアクセスするオペレーティング システム権限を持っていないか、正しいネットワークにログインしていません。
•クライアント リクエスターが有効ではありません。
•データベース サーバー エンジンがインストールされていないか、実行されていません。
•データベース サーバーがリモート接続を受け付けません。
•リモート データベースが DSN セット アップをネットワーク上に通知していません。
•ローカル クライアントがサーバーにアクセスするための DSN を持っていません。
•クライアントまたはサーバー ネットワーク設定が間違っています。
►問題の実際の原因を調べるには
以下の手順に従って、基本的な設定に問題がないかどうかを確認しながら原因を特定してください。
1 接続するサーバー コンピューターを見つけることができる場合は、Windows クライアント上のオペレーティング システムからネットワーク情報にアクセスして表示します。サーバーを表示することができる場合は、そのサーバーがダウンしていない、またはネットワークから切断されていないことが確認できます。
2 次に、あるドライブをファイル サーバーにマップ、またはサーバー上の共有ファイルを開いてみます。ファイル サーバーへ接続し、マップされたドライブ上にファイルを作成することができた場合、オペレーティング システム権限を持っていることが確認できます。また、正しいネットワークにログインしていることも確認することができます。特定のネットワークにログインしていない場合、そのネットワーク上のサーバーにはまったくアクセスすることはできません。
メモ： サーバー上に新しいデータベースを作成する場合にリモート サーバー エンジンに対して Monitor を使用したり、またはリモート サーバーを設定するには、サーバー上での管理者権限を持っているか、あるいは Pervasive_Admin のメンバーである必要があります。単純なドライブのマッピングや共有ファイルの読み込みでは、管理者権限を持っているかどうかわかりません。つまり、ファイル サーバーへ接続することは可能でも、設定プロパティ、Monitor、またはデータベース作成ウィザードを使ってデータベース エンジンに接続することはできない場合があるということです。
3 次に考えられる原因は、クライアント リクエスターが無効である可能性です。
PCC を起動し、お使いのローカル クライアント コンピューターを示すアイコンを右クリックして［プロパティー］をクリックします。［アクセス］をクリックし、［リモート MicroKernel エンジンの使用］が選択されていることを確認します。
これにより、リクエスターには問題がないことが確認できます。
4 次に、Pervasive PSQL がターゲット サーバー上にインストールされ、起動しているかどうかを調べます。
Windows で、［管理ツール］の［サービス］を開きます。Pervasive PSQL Transactional Engine および Pervasive PSQL Relational Engine が開始されていることを確認します。停止していた場合は、これらのサービスを開始します。
Linux では、データベース エンジンがインストールされているサーバー上の Linux プロンプトで以下のコマンドを入力します。
ps -e | egrep 'mkded'
コマンドからの出力で、テキスト "mkde" を含む最低 1 行が返された場合、Pervasive PSQL が起動しています。この行が表示されない場合、root アカウントにログインし、以下のように入力してデータベース エンジンを起動する必要があります。
/etc/init.d/psql start
これで、サーバー エンジンがインストールされ、起動していることが確認できます。
5 次の手順では、サーバー エンジンがリモート通信リクエストを受け付けているかどうかを確認します。
PCC で、リモート データベース エンジンがリモート リクエストを受け付けるよう設定されていることを確認します。リモートで Windows 32 ビット サーバー エンジンにアクセスすることが困難な場合は、サーバーで直接設定を確認する必要があります。これを行うには、サーバーでの管理者権限を持っている（または、Pervasive_Admin グループのメンバーである）必要があります。PCC でサーバーを右クリックし、次に［プロパティー］をクリックします。［アクセス］をクリックし、［リモート リクエストの受付］が選択されていることを確認します。
これにより、サーバーがリモート リクエストを受け付けていることが確認できます。
6 メモ：アプリケーションで ODBC を使わず単に Btrieve アクセスのみを使用していた場合は、この手順を省きます。
今までの確認事項を満たした上で、まだデータをアクセスできない場合は、ターゲット データのサーバー DSN が設定されているかどうかを確認します。PCC を使用してサーバーの［データベース］ノードを開き、存在するデータベースを調べることができます。データベースの中で、アクセスするデータが存在することを確認します。そうであれば、サーバー DSN はデータ用に作成されています。
アクセスしたいデータは見つからないが、サーバー上にそのデータが存在していることがわかっているときは、ほとんどの場合、そのデータ用の DSN を設定する必要があります。これを行うには、サーバーでの管理者権限を持っている（または、Pervasive_Admin グループのメンバーである）必要があります。
ODBC データベース アクセスの設定の手順に従い、既存のデータ ファイル用の DSN を設定します。
これにより、サーバー DSN には問題がないことが確認できます。
7 メモ：アプリケーションで ODBC を使わず単に Btrieve アクセスのみを使用していた場合は、この手順を省きます。
上述のすべての手順を実行した上で、まだデータにアクセスできない場合は、次にリモート データのローカル クライアント DSN が設定されているかどうかを確認します。
PCC では、クライアント DSN なしの接続を使用してリモート サーバー データ ソース（DSN）にアクセスできます。Microsoft Excel および Access などの多くのデスクトップ アプリケーションではこれが行えません。ローカル コンピューター上でクライアント DSN を作成し、リモート サーバー DSN にアクセスできるようにします。クライアント DSN を再作成するには、
Windows クライアントからのクライアント アクセスの設定の手順に従ってください。最初に、アクセスするサーバー上にサーバー DSN が存在していることを確認する必要があります。
これにより、クライアント DSN には問題がないことが確認できます。
8 最後に、クライアントとサーバーが適切なネットワーク プロトコル上で通信しているかどうかを確認します。デフォルトで、Pervasive PSQL ではすべてのネットワーク プロトコルを有効にして送るため、すべてのプロトコルの試行によって接続時間は遅くなりますが、最終的には接続します。アプリケーションで通常使用しないプロトコルを無効にするアプリケーション ベンダーもあります。
最初に、ネットワーク上で使用しなければならないプロトコルを決定します。Linux ネットワークまたは 完全な Microsoft ネットワークの場合、適切なプロトコルは TCP/IP です。
適切なプロトコルがわかれば、サーバーがそのプロトコルを使用していることを確認する必要があります。サーバー オペレーティング システムでの管理者権限を持っている（または、Pervasive_Admin グループのメンバーである）必要があります。PCC でサーバー名を右クリックし、次に［プロパティー］をクリックします。［通信プロトコル］をクリックします。［サポート プロトコル］の一覧に正しいプロトコルが表示されていて、TCP/IP が選択されていることを確認します。
クライアントが同じプロトコルを使用していることを確認します。PCC を使用し、ローカル クライアントを右クリックし、次に［プロパティー］をクリックします。［通信プロトコル］をクリックし、［サポート プロトコル］で正しいプロトコルが選択されていることを確認してください。
PCC は大きなレコード セットを取得する際に処理速度が低下したりハングしたりします。
このような問題が起きた場合は、PCC の起動時に使用できるメモリを増やしてみてください。指定できるメモリ量は、お使いのマシン上にインストールされている物理メモリによってのみ制限されます。最小および最大メモリ量を指定できます。たとえば、最小および最大に 256 メガバイトを指定するには、PCC を以下のコマンドで起動します。
pcc.exe -vmargs -Xms256M -Xmx256M
パラメーター -vmargs は、その他のパラメーターを指定する場合に必要です。
パラメーター -Xms は PCC に割り当てるメモリの最小量を指定します。パラメーター -Xmx は PCC に割り当てるメモリの最大量を指定します。-Xms パラメーターを指定した場合は、-Xmx パラメーターも指定する必要があります。
PCC からのエラー メッセージ
PCC でデータベースを作成またはデータベースに接続しようとする場合に、いくつかの異なるメッセージを受け取ることがあります。このセクションでは、最も一般的なエラー メッセージの主な原因を説明します。
テーブル名を取得できません。操作に必要なアクセス権がありません。
このエラーは、サーバー上に新しいデータベースを作成しようとするときに発生します。これはほとんどの場合、サーバー オペレーティング システムの管理者権限を持っていない、またサーバー上で Pervasive_Admin グループのメンバーでもないオペレーティング システム ユーザーとしてログインしていることが原因です。このほか、ユーザー名とパスワードを入力していなかった場合もこのエラーの原因になります。
解決方法：リモート オペレーティング システムに対するユーザー名とパスワードを入力したことを確認します。サーバー上に新しいデータベースを作成するための、サーバーでの管理者権限を持っている（または、Pervasive_Admin グループのメンバーである）必要があります。
データベース エンジンの管理者権限の許可では、Pervasive_Admin グループの設定方法を説明しています。
Windows 32 ビット プラットフォーム の場合、ネットワーク ユーザーではなく、システム上のローカル ユーザーとして設定されていることを確認してください。ネットワーク ユーザーは、BOSTON\GILBERT のようにドメイン名と円記号（\）に続いたユーザー名を持ちます。Administrators グループまたは Pervasive_Admin グループのメンバーであるユーザーは、ローカル ユーザーであることを確認してください。
必要な権限を持ち、ユーザー ログインが実際に上記の条件の 1 つを満たしている場合は、次に正しいネットワークにログインしているかどうかも確認してください。ターゲット オペレーティング システムを使用していることが確実なサーバーに読み込みまたは書き込みを試行すれば、正しいネットワークにログインしているかどうか調べることができます。
指定のリモートエンジンに接続できません。通信コンポーネントがすべてリモート サーバーにロードされており、使用可能なセッションがあることを確認し、再試行してください。
PCC で新しいリモート サーバーを登録しようとするときに、このエラーを受け取る場合があります。このエラーが表示される場合は、いくつかの原因があります。
1 サーバー名を間違って入力しています。データベース クライアントは存在しないサーバーに接続しようとしています。
解決方法：サーバー名を再確認し、入力したサーバー名と同じサーバーがネットワークで表示されるかどうかを確認します。
サーバーが存在していることはわかっているが、それがネットワークで表示されない場合は、正しいネットワークにログインしているかどうかを確認してください。ネットワーク管理者に確認してください。
2 サーバーのユーザー カウントの有効期限が切れています。一時的なライセンスを使用している場合、ライセンスの有効期限が過ぎた後に接続を行おうとするとこのメッセージが表示されます。
解決方法：License Administrator を起動してサーバーにインストールされたライセンスのステータスをチェックします。表示されるウィンドウで、サーバーに適用されている各ライセンスに関する詳細なステータス情報を見ることができます。ライセンスの有効期限が切れていた場合は、販売店または株式会社エージーテックから正式なライセンスをご購入ください。
3 サーバー上に有効なセッションがありません。サーバー上で負荷の大きいロードを行うユーザーがいる場合、またはサーバーで小さいセッション数が設定されている場合はこのエラーを受け取る場合があります。
解決方法：Monitor を起動してサーバー上で有効なセッションの使用をチェックします。Monitor で、［オプション｜接続］を選択し、チェックするサーバーに接続します。次に、［MicroKernel｜通信］を選択します。表示されるウィンドウ内で、［リモート セッション総数］を探します。その［ピーク値］と［最大値］の値が同じ場合は、セッションが不足していると考えられます。
4 リモート データベース サーバーが起動していません。
解決方法： リモート データベース エンジンが起動していることを確認してください。また、起動する場合は、ネットワーク管理者に依頼してください。
5 リモート データベース サーバーがクライアントのリクエストを受け付けていません。
解決方法：プロパティを設定して、リモート データベース エンジンがリモート リクエストを受け付けるようにします。これを行うには、サーバーでの管理者権限を持っている（または、Pervasive_Admin グループのメンバーである）必要があります。PCC の Pervasive PSQL エクスプローラー でサーバー名を右クリックし、次に［プロパティー］をクリックします。［アクセス］をクリックし、［リモート リクエストの受付］オプションが選択されていることを確認します。
サーバーへの接続に失敗しました。
このエラーはほとんどの場合、オペレーティング システムのユーザー名またはパスワードを間違えてサーバーに接続しようとしていることが原因です。
ほかに考えられる原因は次のとおりです。
•オペレーティング システムで、ユーザーが最初のログオン時のパスワードを変更することを要求する場合があります。この状況が発生するのは、ユーザー マネージャーで［ユーザーは次回ログオン時にパスワード変更が必要］チェックボックスをオンにしている場合です。
•ユーザーが、制限された権限を持つほかのグループのメンバーの場合、その制限付きの権限が優先されます。ユーザーは常に、そのユーザーが属するグループの制限された権限のみを持ちます。
解決方法：ユーザー名とパスワードを再確認します。そのユーザー名とパスワードがリモート サーバーのオペレーティング システムで設定されていることを確認します。
サーバー上でのユーザーのアカウント情報を調べます。オペレーティング システムで、ユーザーのパスワードが次回のログオン時に変更されることがないことを確認します。そのユーザーが、制限された権限を持つグループのメンバーでもないことを確認します。
Windows 32 ビット プラットフォームの場合、ユーザーがネットワーク ユーザーではなく、システム上のローカル ユーザーとして設定されていることを確認してください。ネットワーク ユーザーは、BOSTON\GILBERT のようにドメイン名と円記号（\）に続いたユーザー名を持ちます。Administrators グループまたは Pervasive_Admin グループのメンバーであるユーザーは、ローカル ユーザーであることを確認してください。
不明な設定プロパティ
PCC がデータベース エンジンから無効な設定プロパティを取得することは、可能性はありますが、ほとんどありません。そのようなエラーについては、Pervasive のカスタマー サポートにご連絡ください。
Pervasive PSQL のリソースおよび問い合せ先を参照してください。
よく寄せられる質問
このセクションでは、お客様からよくお問い合わせのある質問にお答えします。質問の一覧を以下に示します。
インストール
PCC
セキュリティ
ユーザー数、セッション数、使用データ
ネットワーク
データ アクセスでの問題
ODBC と DDF
Btrieve 6.15 からのアップグレード
アップグレードおよび移行
DEMODATA サンプル データベース
DEMODATA をデフォルトの状態に復元する方法はありますか？
［データベースの選択］ダイアログが表示されます。
3 一覧から "DEMODATA" エントリをクリックして［OK］をクリックします。
PCC 内に SQL Editor タブが表示されます。
4 ［ファイル｜開く］をクリックします。
5 DEMODATA.sql ファイルの場所に移動してそのファイルを選択し、［開く］をクリックします。
Pervasive PSQL ファイルのデフォルトの保存場所については、『
Getting Started with Pervasive PSQL』の
Pervasive PSQL ファイルはどこにインストールされますか？を参照してください。
6 ［
SQL｜すべての SQL ステートメントを実行］をクリック、
F10 を押す、または
をクリックします。
DEMODATA.sql では既存のテーブルを削除してから、インストール時のデフォルトを使用してそれらのテーブルを再作成します。復元されたテーブルは空（データなし）です。
DEMODATA の一部として新規作成したテーブルは削除されません。
7 バルク データ ユーティリティ（BDU）を使用してデータをテーブルに入れてください（
bduを参照）。
a. コマンド プロンプトを開きます。
b. DEMODATA の "restore" ディレクトリに移動します。DEMODATA のテーブルごとに "SDF" ファイルが存在します。
c. SDF ファイルごとに、BDU を使用してデータをテーブルに読み込みます。
たとえば、"Billing" テーブルのデータを読み込むには次のコマンドを使用します。カンマはファイルのフィールド区切り文字です。
bdu demodata billing billing.sdf -t ,
メモ： "-t ," パラメーターは必要です。
BDU ユーティリティでは、読み込まれたデータの行数を返します。
その他
インストール
インストール後によく寄せられる質問
既存のバージョンの製品をアンインストール、または新しいバージョンをインストールすると、データ ファイルはなくなってしまいますか？
Pervasive PSQL をアンインストール、または新しいバージョンの Pervasive PSQL をインストールした場合、以前のデータ ファイルおよび DDF がなくなることはありません。Pervasive System Analyzer で Pervasive PSQL ファイルを整理して保持した場合でも、あるいは Pervasive PSQL ファイルと同じディレクトリにデータ ファイルがあった場合でも、以前のデータ ファイルには影響がありません。
インストールまたはアップグレードしたばかりの「プラグイン」製品が PCC の Pervasive PSQL エクスプローラー に表示されないのはなぜでしょう？
どのタイプのクライアント インストールを行うべきでしょうか？
わからない場合は、常に「すべて」を選択してください。このオプションは、標準インストールを行います。このインストールでは問題が発生した場合にトラブルシューティングがより簡単になります。
実行しているクライアントのサービス パックのレベルはどのようにしたら確認できますか？
Pervasive PSQL v11 SP3 を使用している場合、Monitor または Maintenance を起動して、メニューから［ヘルプ｜バージョン情報］を選択し、ビルド レベルを調べます。
Pervasive PSQL はターミナル サーバー上でサポートされますか？
ターミナル サーバー上では、サーバーおよびワークグループ エンジンの両方が Pervasive.SQL 2000i SP4 からサポートされています。Pervasive.SQL 2000i SP3 ではサーバー エンジンのみサポートしています。Pervasive.SQL 2000i SP2 はクライアント ソフトウェアのみをサポートしています。
フェイルオーバーの環境に Pervasive PSQL をインストールできますか？
また、クラスタリング環境に Pervasive PSQL をインストールできますか？
はい。Pervasive PSQL は Microsoft Failover Cluster、Microsoft Cluster Service、および Linux Heartbeat とクラスターの互換性があります。『
Advanced Operations Guide』の
高可用性のサポートの章を参照してください。
ロード バランス環境に Pervasive PSQL をインストールできますか？
これは、現時点ではサポートされません。
Btrieve v6.x またはそれ以前のバージョンを実行しているサーバー上に Pervasive PSQL をインストールできますか？
Pervasive PSQL と Btrieve 6.x を同じコンピューター上で同時に実行することはできません。
再起動したときに、ワークグループエンジンが自動的に起動しないようにするにはどうしたらよいですか？
Windows のスタートアップ グループからワークグループ エンジンを削除する必要があります。スタートアップの詳細については、オペレーティング システムのドキュメントを参照してください。
PCC
PCC に関してよく寄せられる質問
Linux での PCC の起動方法は？
Linux 上で PCC を起動するには、一定の要件を満たす必要があります。
Linux での PCC の起動を参照してください。
セキュリティ
セキュリティに関してよく寄せられる質問
オペレーティング システムのユーザーとパスワードを使用してログインする場合と、データベースのユーザーとパスワードを使用してログインする場合の違いは何ですか？
最初は混乱しやすいのですが、実際には 1 つの規則があるだけです。既にサーバーへの接続が成功しており、データベースに直接アクセスしようとする場合にのみ、データベース ログインを使用します。この時点に達するまでは、オペレーティング システムのログインを使用する必要があります。
たとえば、Monitor を実行してまたは設定プロパティからリモート サーバー エンジンで作業する場合は、パスワードの入力が必要です。いずれの場合でも、リモート システム上での管理者権限を持つオペレーティング システム アカウントまたは Pervasive_Admin のメンバーのアカウントのユーザー名とパスワードを提供する必要があります。これは、新規データベースを作成する場合にも適用されます。
データ自体で作業を始めた後で入力が必要な場合は、データベースのユーザーとパスワードを使用します。データベースのセキュリティを無効にした場合は、データベースのユーザー名とパスワードはまったく必要ありません。この場合、前の段落で述べたような管理者用のタスクを行うためのオペレーティング システムのユーザーとパスワードが必要なだけです。
Pervasive_Admin グループが定義済みまたは管理者権限を持っているのに "ログイン失敗"のメッセージを受け取るのはなぜですか?
Pervasive PSQL サービスの設定は、データベース エンジン実行中のマシンへのログイン許可を持つかどうかに影響します。設定は、Pervasive_Admin グループを使用するかどうかにも適用されます。Pervasive PSQL サービスの［アカウント］への［ログオン］設定を変更した場合、そのアカウントのユーザー権利ポリシーを［オペレーティング システムの一部として機能］に変更する必要があります。そうでない場合、リモート ログインは失敗します。
たとえば、Monitor ユーティリティは、データベース エンジン実行中のマシン上のオペレーティング システムにログインしていることを必要とします。［アカウント］に指定したアカウントがオペレーティング システムの一部として機能しない場合、ログイン失敗のメッセージを受け取ります。
Administrator アカウントであっても、ユーザー権利ポリシーを［オペレーティング システムの一部として機能］に設定する必要があるので注意してください。
ユーザーの権利ポリシーを変更する手順の詳細は
サービスの設定とログイン権限を参照してください。
ユーザー数
ユーザー数に関してよく寄せられる質問
ユーザー数のアップグレードはどのように認証すればよいですか？
ライセンス管理で説明したタスクを参照してください。
ワークグループ エンジンでは、データにアクセスするユーザー数をどのように監視するのですか？2 つのエンジンで同時にデータにアクセスした場合はどうなりますか？
ワークグループ エンジンは、サーバー エンジンが行うのとまったく同様にユーティリティを追跡します。各ライセンスにはユーザー カウントが明記されています。 ユーザー カウントにより、指定された数のコンピューターが、Pervasive データベース エンジンに同時に接続できます。 Pervasive PSQL はシリアル番号によってマシンを識別するので、同じシリアル番号による接続はすべて同一マシンからのものと認識されます。たとえば、複数の NIC を持つ 1 台のマシンは同じマシンとして認識されます。
Pervasive PSQL にクライアント セッションとしてアクセスする各ワークステーションは、1 ユーザーとカウントされます。1 台のクライアント コンピューター上にある複数のアプリケーションは、1 ユーザーと見なされ、別個のユーザーとしてカウントされません。それぞれのターミナル サーバー セッションも 1 ユーザーとしてカウントされます。
Pervasive PSQL は、同じクライアント コンピューター セッションから受信する一意のプロトコルごとに 1 つのユーザー カウントを使用します。あるアプリケーションが TCP/IP を使用し、別のアプリケーションが SPX を使用する場合、これらのアプリケーションが同一マシン上で実行されると、2 ライセンスとカウントされます。同じプロトコルで異なるアドレス形式を使用している場合は、1 ユーザーのみカウントされます。たとえば、あるアプリケーションが IPv4 を使用し、別のアプリケーションが IPv6 を使用する場合、これらのアプリケーションが同一マシン上で実行されると、1 ユーザーのみがカウントされます。IPv4 および IPv6 はそれぞれ TCP/IP の異なるアドレス形式です。
Pervasive PSQL ワークグループ エンジンには試用ライセンスが含まれています。このワークグループ エンジンのライセンスは認証解除できません。
データ ファイルには、一度に 1 つのエンジンのみがアクセスを許可されています。エンジンは、データ ファイルが破損しないように排他モード（ファイル共有しない）でデータ ファイルを開くので、2 つ目のエンジンはファイルを開こうとしてもロック アウトします。
ワークグループ エンジンは、コンカレント ライセンスを使用しますか？または 1 台ごとのライセンスを使用しますか？
コンカレントを使用します。
ユーザー カウント ライセンス モデルを参照してください。
PSQL Server から PSQL Vx Server サーバーへの移行を考えています。これは、ユーザー数に基づくライセンスからデータの使用量に基づくライセンスへ移行するということです。自分の Vx Server ライセンスに適したサイズはどのように調べることができますか？
Capacity Usage ビューアーはこのような目的のために設計されています。使用するセッション数とデータ使用量のピーク値を毎日記録するので、それぞれの数量を経時的に見ることができます。この情報を使用して、Vx Server に必要なライセンス サイズを合理的に判断することができます。Capacity Usage ビューアーのアクセス方法および使用方法については、
Capacity Usage ビューアーを参照してください。
ネットワーク
ネットワークに関してよく寄せられる質問
通信に使用しているプロトコルを知るにはどうしたらよいですか？ネットワークでほかのシステムが表示されますが、自分のデータを見ることができません。
Pervasive System Analyzer を起動し、初期画面で［次へ］をクリックします。次の画面で、［アクティブ インストールをテストする］を選択して［ネットワーク通信をテストする］チェック ボックスをオンにし、その他のチェック ボックスをすべてオフにします。 ［次へ］をクリックします。次の画面で［詳細設定］をクリックし、テストしないプロトコルの選択をオフにして［OK］をクリックします。参照ボタン［...］をクリックして、サーバー上のインストール ディレクトリにマップしたドライブを選択します。ドライブは、マップしたドライブでなければなりません。UNC 名はサポートされません。［次へ］をクリックしてネットワーク テストを実行します。ネットワークで重大な問題があれば、結果ウィンドウで通知されます。
データ アクセスでの問題
データ アクセスに関してよく寄せられる質問
v6.x 以前の Btrieve から Pervasive PSQL v11 SP3 にアップグレードしました。ほかの誰もがアクセス可能な場合でも、ファイルにアクセスできないとのエラー メッセージが表示されるようになりました。何が間違っているのでしょうか？
Pervasive System Analyzer を使用して Btrieve または Pervasive PSQL の以前のバージョンのコンポーネントがすべて保持されているかどうかを確認します。次に、環境設定が正しいかどうかを確認してください。pvsw.log ファイルを探し、ステータス コード 8505 または 8517 を示すエラー メッセージをチェックします。これらのステータス コードは、データ ファイルを読み込むためにローカルのワークグループ エンジンの使用を試行したことを示します（pvsw.log に書き込まれるメッセージ文字列に 16 進数値が含まれる場合、その 16 進数値の前には "0x" が付くので 10 進数値と区別できます）。
PCC を起動します（『
Pervasive PSQL User's Guide』の
Windows での PCC の起動を参照してください）。［
ローカル クライアント］を右クリックして［
プロパティー］を選択します。［
アクセス］をクリックします。［
ローカル MicroKernel エンジンの使用］オプションのチェックが
オフで、［
リモート MicroKernel エンジンの使用］オプションのチェックが
オンになっていることを確認してください。
サーバー上にファイルが存在し、共有になっていますが、Pervasive PSQL でそれを読み込むことができません。何が間違っているのでしょうか？
ファイルはどのように共有していますか？Pervasive では Microsoft でのリダイレクトされたマップ、または Windows 32 ビット プラットフォーム での 非表示の Admin 共有（C$）を使用したドライブ名のマップをサポートしません。
ユーザーが、ファイル サーバーへアクセスするためのオペレーティング システムの適切なログイン認証を持っているかどうかを確認してください。
Pervasive System Analyzer を実行し、［ネットワーク通信をテストする］を選択して接続が正しく行えるかどうかを確認します。
SQL クエリを使用して旧テーブルの定義を作成しています。結果レコードのサイズが異なってしまいました。なぜでしょう？
Pervasive.SQL 2000 で実行した場合、ヌル値を許可するフィールドでは、そのフィールドの開始位置に定義された追加バイトがあります。このバイトはヌル インジケーターです。次のいずれかの方法でこれを変更することができます。
SQL ステートメントを使用して新しいテーブル定義を作成する場合は SET TRUENULLCREATE=OFF というステートメントを入力します。現在のセッションではこれ以降、作成するテーブルは旧レコードの構造を使用し、ヌル値を許可する各列に余分なバイトを追加しません。
SQL ステートメントを使用しない場合は、すべての列をヌル値が許可されないようにして作成し、フィールドのサイズを取得して適切に配置することができます。
バージョン 9 のデータ ファイルをバージョン 8、7 または 6 のファイル形式に変換したいのですが、どのようにすればよいですか？
変換するファイルがリモート サーバーまたはワークグループ エンジンによって提供される場合は、以下のタスクを行うためにリモート システム上での管理者権限を持っている必要があります。また、リモート データ ファイルにマップしたネットワーク ドライブが必要です。
PCC でデータ ファイルが存在するサーバー名を右クリックし、次に［プロパティー］をクリックします。［ファイル互換性］をクリックし、［作成ファイルのバージョン］に変換するファイル バージョンを設定します。［OK］をクリックします。［はい］をクリックして、エンジンを再起動します。これらの変更によって、選択したバージョンで新しいファイルが作成されます。
Maintenance ユーティリティを実行して、［オプション］メニューから［情報エディタの表示］を選択します。［情報のロード］をクリックして、変換するデータ ファイルを選択します。［ファイルの作成］をクリックして、旧バージョン形式で作成する新しい空のデータ ファイルの名前を指定します。［OK］をクリックしてファイルを作成します。［ファイル情報エディター］ウィンドウは閉じますが、Btrieve Maintenance ユーティリティは終了しないでください。
メニューから、［データ｜コピー］を選択します。ソース データ ファイル名とターゲット データファイル名（旧バージョンのファイル形式で新規に作成するファイル）を入力します。［実行］をクリックしてレコードを旧バージョンのファイルへコピーします。コピーが完了した後、新しいデータ ファイルをコピー元のファイル名と同じ名前にする必要がある場合は、元のデータ ファイルを別名で保存し、元のファイル名で新しいファイルを保存します。
ODBC と DDF
ODBC および辞書ファイルに関してよく寄せられる質問
ODBC を使用してデータ ファイルにアクセスできるかどうかを知るにはどうしたらよいですか？
調べる方法はいくつかあります。まず、データ ファイルが置かれている場所で DDF ファイルを探します。これらが見つかれば、ほとんどの場合は ODBC を使用してデータベースにアクセスできます。DDF ファイルはデータ ファイルと異なるディレクトリに置くことができるので、PCC を使用して、アクセスするデータ ファイルのデータベースが作成されているかどうかを調べる必要もあります。また、アプリケーションでデータ ファイルのアクセスに ODBC を使用しているかどうかをアプリケーション ベンダーに尋ねることができます。
DDF のコード記述されたファイルパスはどのようにしたら変更できますか？
PCC で、テーブルが属するデータベースを右クリックしてから［プロパティー］をクリックします。［ディレクトリ］をクリックします。［辞書のロケーション］の値を変更します。
パスは変更されていないように見えます。変更を確認するには、X$File システム テーブルを開き、指定したユーザー テーブルの Xf$Loc フィールドを見ます。PCC にシステム テーブルが表示されていない場合は、［システム オブジェクト］を展開します。
また、SQL で ALTER TABLE USING ステートメントを使用して、特定のテーブルによって使用されるデータ ファイルを変更します。詳細については、『SQL Engine Reference』を参照してください。
データ辞書（DDF）の安全性を確保する一番よい方法はなんですか？
常に DDF のバックアップ コピーを行ってください。ランタイム DDF を変更するときには、必ず変更前にその DDF のバックアップ コピーを行ってください。最初にデータベースのセキュリティを有効にする場合は、セキュリティなしの辞書のバックアップ コピーと、セキュリティ付きの辞書のバックアップ コピーを行います。
非標準 DDF を使用しているかどうかを知るにはどうしたらよいですか？
Btrieve ユーティリティで編集できる場合、その DDF は標準の辞書ファイルではありません。標準の辞書ファイルは、Btrieve で直接アクセスすることができません。このロック アウトは、SRDE のみが辞書へ書き込みできることを保証する安全な機能です。DDF は互いに、そしてデータ ファイルと常に同期化されている必要があるたいへん重要なファイルです。
標準の辞書のテーブル名およびフィールド名は大文字小文字を区別しません。file.ddf の列 Xf$Name と field.ddf の 列 Xe$Name の列定義で大文字小文字を区別するかどうかを設定するフラグがあり、これらの値が大文字小文字を区別しないこと示しています。
DDF は Btrieve ファイルなので、Function Executor を使用して開き、表示することができます（更新はできません）。これは、file.ddf または field.ddf の内容を確認する 1 つの方法です。
非標準の辞書 DDF のなかには、file.ddf、field.ddf および index.ddf のすべて、またはいずれかが存在しない場合があります。このような辞書は、本製品で動作しません。たとえば、file.ddf ではなく x$file.ddf というファイルがある場合は、その DDF は非標準であることがわかります。
非標準の DDF は、おそらく Pervasive PSQL Control Center またはリレーショナル エンジンで正しく動作しません。
異なるデータベース間で DDF を混合して統合させることができますか？
DDF ファイルの完全なセットは 1 つの単位として考える必要があります。DDF を 1 つも持たないデータベースと別のデータベースの DDF とを混合することができます。
DDF Sniffer はどうなったのでしょう？
DDF Sniffer は、1998 年に Smithware からの権利の取得により Pervasive 製品に追加されました。現在は別個の製品としては使用できません。この機能の大半は Pervasive PSQL Control Center および DDF Builder に置き換えられました。
類似する 2 つの Btrieve ファイルがあり、一方のファイルに DDF を作成しました。2 つのファイルは類似しているので、もう一方の Btrieve ファイルでも同じ DDF を使うことができますか？
2 つのファイルがどのように似ているかによって答えは異なります。2 つのファイルのレコード数が違うだけなら、同じ DDF ファイルを使用することができます。フィールドまたはインデックスの数、順序、名前または型が異なれば、同じ DDF は使えません。つまり、2 つのファイルのレコード構造が完全に一致している場合にのみ同じ DDF が使用できます。
Btrieve ファイルのオーナー ネームのセットを持っています。DSN を作成した後で、ODBC を使用してファイルを開くことができません。何が間違っているのでしょうか？
Btrieve ファイルがオーナー ネームを持つ場合、ODBC アクセスにはデータベース セキュリティを使用する必要があります。PCC でデータベース セキュリティを有効にしてください。『
Advanced Operations Guide』の
Pervasive PSQL エクスプローラーを使ってセキュリティをオンにするにはおよび
オーナー ネームおよびセキュリティを参照してください。
注意： Master ユーザーのパスワードは忘れないでください。パスワードがないと、データベース内でセキュリティを無効にしたり管理者タスクを実行することはできません。パスワードを忘れてしまった場合に備えて、セキュリティを有効にする前に DDF をバックアップしておくこともできます。
次に、オーナー ネームを定義したデータ ファイルへの Master ユーザー アクセスを許可します。オーナー ネームを持つ各テーブルに対し、次の SQL ステートメントを発行することによってアクセスを許可することができます。
GRANT ALL ON my_table 'ownername' TO Master
上記のステートメントを入力する場合は、変数個所をテーブルの実際の名前とそのテーブルの適切なオーナー ネームに置き換えてください。各データ ファイルは ODBC テーブルに対応していることを覚えておいてください。どのテーブルがどのデータ ファイルに対応しているかがわからない場合は、PCC を使用して見つけてください。PCC でテーブルを右クリックし、次に［プロパティー］をクリックします。ツリーで［情報］をクリックします。［テーブルの場所］フィールドは、そのテーブル定義によって参照されるファイルを示します。
セキュリティが重要な場合は、ユーザーを作成し、データベースにアクセスすると思われるすべてのユーザーに権限を割り当てます。これは、SQL で CREATE GROUP および GRANT ステートメントを使用して行います。その後、PCC でユーザーやグループを追加することができます。『
Advanced Operations Guide』の
ユーザーとグループを参照してください。
セキュリティが重要でない場合、PUBLIC にアクセスを許可すれば、多くのユーザーの作成や権限の割り当てを行う必要がありません。PUBLIC ではネットワーク上のだれもがデータにアクセスできます。次のステートメントを使用することができます。
GRANT ALL ON my_table 'ownername' TO PUBLIC
SRDE 用のクライアント側のリクエスターがありますか？
SQL アプリケーションをサポートする DOS リクエスターはありませんが、Windows 用の Pervasive PSQL クラインアント ソフトウェアには ODBC クライアント コンポーネントが含まれており、リモート SRDE サーバー エンジンへ接続することができます。
Pervasive PSQL のアクセス方法は ODBC のみですか？
いいえ、ほかにも方法があります。ODBC や長年その有効性が認められている Btrieve API に加え、OLE DB プロバイダー、JDBC ドライバー、純粋な Java インターフェイス、あるいは ActiveX コントロールを使用してアプリケーションを開発できます。
ほかのいくつかの製品のように、すべてのデータ、データ定義、ストアド プロシージャ、セキュリティ、テーブルの関係などが含まれる単一のデータベースがありますか？
ありません。Pervasive PSQL は、データを別々のファイルに保存します。リレーショナル テーブル定義ごとに 1 つのファイルとなります。データ定義、ユーザー/グループ定義などのメタ データは DDF ファイルのセットに保存されます。各 DDF ファイルの拡張子は ".ddf" です。
SQL エンジン（SRDE）には、データにアクセスまたはデータに影響するようデザインされたストアド プロシージャ、またはほかのタイプのスクリプトを実行できるスケジューラがありますか？
SRDE にはスケジューラがありません。
Btrieve 6.15 からのアップグレード
Btrieve 6.15 に関してよく寄せられる質問
Xtrieve に置き換わるツールがありますか？
完全な代替ツールはありませんが、Btrieve データによるレポート作成およびクエリに関しては、Xtrieve からの有効なアップグレードとして Crystal Reports for Btrieve を使用することを検討してください。
アップグレードおよび移行
アップグレードと移行に関してよく寄せられる質問
既存の Btrieve ファイルを使用してテーブルを作成する場合、ウィザードで表示される列数が実際の Btrieve ファイルの列数より少ないです。何が間違っているのでしょうか？
Btrieve ファイルに含まれるファイルの構造に関する情報量は限られています。テーブル作成ウィザードでは、インデックスを使用していくつかのフィールド定義を解釈できますが、インデックスを使い果たすと、2 つ以上の実際のフィールドを含むデータ セグメントが残る場合があります。ウィザードでは内容を解析する方法がありません。レコード構造をよく理解してこれらのフィールドを分割し、レコード内のすべてのフィールドと一致するテーブル定義をビルドする必要があります。
このタスクの手順は、『Advanced Operations Guide』で説明しています。
以前のバージョンの製品から Pervasive PSQL v11 SP3 への移行に関する情報はどこにありますか？移行および互換性に関する情報はどこにありますか？
『Getting Started with Pervasive PSQL』にはアップグレード方法の詳細な手順を説明する章があります。
その他
その他のトピックに関してよく寄せられる質問
Btrieve レコードをファイルにダンプしたのですが、そのファイルを読み込むことができませんでした。どうしてでしょう？
Btrieve の Maintenance ユーティリティを使用してレコードを保存/ダンプした場合、結果ファイルには各レコードのバイナリ イメージが含まれます。レコードが文字データで完全に構成されなければ、実際の内容を読み取ることができません。
Pervasive PSQL が ASCII の読み取り可能な形式でレコードをダンプできる唯一の方法は、DDF を読み込んで、レコードの全内容の記述を取得することです。Btrieve ではレコード長、インデックスのデータ型およびインデックスの長さのみを持ちます。Btrieve には、レコード全体の内容を解釈する方法についての情報がありません。
トレース モードで Pervasive PSQL を実行するにはどうしたらよいですか？
サーバー
デバッグ モードで実行するエンジンが置かれているコンピューターでの管理者権限を持っていなければなりません。
1 PCC を使用し、目的のサーバー エンジンを右クリックし、次に［プロパティー］をクリックします。
2 ［デバッグ］をクリックし、［トレース オペレーションの実行］オプションをオンにします。
3 ［OK］をクリックします。
エンジンを再起動する必要はありません。
『
Advanced Operations Guide』の
トレース オペレーションの実行も参照してください。
メモ： オペレーションをトレースした後は［トレース オペレーションの実行］オプションをオフにし、［適用］をクリックします。トレース モードで Pervasive PSQL を実行した場合、パフォーマンスが低下します。
Windows クライアント
PSA ネットワーク接続テストを実行し、ネットワーク接続を確認します。
アクティブ インストールのテストを参照してください。
さらに、ある種の低レベルな問題のトラブルシュートにはクライアントのトレースが使用できます。一般的に、低レベルのトレースは不要で、このようなトレースは熟練したサポート スタッフが使用するためのものです。低レベルのクライアントのトレースを実行する方法は、製品のベンダーまたは Pervasive Software のサポートが説明します。
データ ファイルやインデックス内で不要部分削除を行いますか？たとえば、削除したレコードの領域は回復または再利用されますか？
行います。削除したレコードの領域は、以降の挿入で再利用されます。ファイル内の空き領域は、ディスクにデアロケートされることはありません。インデックス バランスがオンになっている場合は、インデックス ページ内の未使用領域も再利用されます。『
Advanced Operations Guide』の
Rebuild ユーティリティの概念を参照してください。
データベースがオンラインでバックアップできる機能は何ですか？多くのトランザクションを開いている状態でバックアップを行っているときにサーバーがダウンした場合はどうなりますか？
Continuous オペレーションを使えば、使用中のデータ ファイルのセットを安全にバックアップできる特別な "セーフ モード" に置くことができます。データ ファイルが Continuous オペレーション モードの間、それらのデータ ファイルは変更されず、特別なデルタ ファイルにすべてのデータベース操作の結果を保存します。バックアップが完了した後、データ ファイルは Continuous オペレーション モードから削除する必要があり、その時点のデルタ ファイルに保存された変更が使用中のファイルにロール インされます。
データ ファイルが Continuous オペレーション モード中にサーバーがダウンした場合、次回そのデータ ファイルにアクセスしたときには、データベース エンジンが既存のデルタ ファイルを検出してその時点の変更をロール インします。
データ ファイルを Continuous オペレーション モードにするには、『Advanced Operations Guide』で説明されている BUTIL -STARTBU コマンドまたは Maintenance ユーティリティを使用します。
SQL ドキュメント］をクリックします（新規 SQL クエリのために SQL Editor を起動するには を参照してください）。