|
このセクションでは、お客様からよくお問い合わせのある質問にお答えします。質問の一覧を以下に示します。
DEMODATA をデフォルトの状態に復元する方法はありますか?
インストール後によく寄せられる質問
Pervasive PSQL をアンインストール、または新しいバージョンの Pervasive PSQL をインストールした場合、以前のデータ ファイルおよび DDF がなくなることはありません。Pervasive System Analyzer で Pervasive PSQL ファイルを整理して保持した場合でも、あるいは Pervasive PSQL ファイルと同じディレクトリにデータ ファイルがあった場合でも、以前のデータ ファイルには影響がありません。
PCC キャッシュをクリアする必要がある状況を参照してください。
わからない場合は、常に「すべて」を選択してください。このオプションは、標準インストールを行います。このインストールでは問題が発生した場合にトラブルシューティングがより簡単になります。
Pervasive PSQL v11 SP1 を使用している場合、Monitor または Maintenance を起動して、メニューから[ヘルプ|バージョン情報]を選択し、ビルド レベルを調べます。
ターミナル サーバー上では、サーバーおよびワークグループ エンジンの両方が Pervasive.SQL 2000i SP4 からサポートされています。Pervasive.SQL 2000i SP3 ではサーバー エンジンのみサポートしています。Pervasive.SQL 2000i SP2 はクライアント ソフトウェアのみをサポートしています。
はい。Pervasive PSQL は Microsoft Failover Cluster、Microsoft Cluster Service、および Linux Heartbeat とクラスターの互換性があります。『Advanced Operations Guide』のフェイルオーバー クラスター サポートの章を参照してください。
これは、現時点ではサポートされません。
Pervasive PSQL と Btrieve 6.x を同じコンピューター上で同時に実行することはできません。
[スタート|プログラム]メニューのスタートアップ グループからワークグループ エンジンを削除する必要があります。
Windows 32 ビット プラットフォーム では、このスタートアップ グループの内容は次の場所にあります。
c:¥Documents and Settings¥ユーザー¥スタート メニュー¥プログラム¥スタートアップ
ユーザー は、必要に応じ "All Users" または任意のユーザーとすることができます。
PCC に関してよく寄せられる質問
Linux 上で PCC を起動するには、一定の要件を満たす必要があります。Linux での PCC の起動を参照してください。
セキュリティに関してよく寄せられる質問
最初は混乱しやすいのですが、実際には 1 つの規則があるだけです。既にサーバーへの接続が成功しており、データベースに直接アクセスしようとする場合にのみ、データベース ログインを使用します。この時点に達するまでは、オペレーティング システムのログインを使用する必要があります。
たとえば、Monitor を実行してまたは設定プロパティからリモート サーバー エンジンで作業する場合は、パスワードの入力が必要です。いずれの場合でも、リモート システム上での管理者権限を持つオペレーティング システム アカウントまたは Pervasive_Admin のメンバーのアカウントのユーザー名とパスワードを提供する必要があります。これは、新規データベースを作成する場合にも適用されます。
データ自体で作業を始めた後で入力が必要な場合は、データベースのユーザーとパスワードを使用します。データベースのセキュリティを無効にした場合は、データベースのユーザー名とパスワードはまったく必要ありません。この場合、前の段落で述べたような管理者用のタスクを行うためのオペレーティング システムのユーザーとパスワードが必要なだけです。
Pervasive PSQL サービスの設定は、データベース エンジン実行中のマシンへのログイン許可を持つかどうかに影響します。設定は、Pervasive_Admin グループを使用するかどうかにも適用されます。Pervasive PSQL サービスの[アカウント]への[ログオン]設定を変更した場合、そのアカウントのユーザー権利ポリシーを[オペレーティング システムの一部として機能]に変更する必要があります。そうでない場合、リモート ログインは失敗します。
たとえば、Monitor ユーティリティは、データベース エンジン実行中のマシン上のオペレーティング システムにログインしていることを必要とします。[アカウント]に指定したアカウントがオペレーティング システムの一部として機能しない場合、ログイン失敗のメッセージを受け取ります。
Administrator アカウントであっても、ユーザー権利ポリシーを[オペレーティング システムの一部として機能]に設定する必要があるので注意してください。
ユーザーの権利ポリシーを変更する手順の詳細はサービスの設定とログイン権限を参照してください。
ユーザー カウントに関してよく寄せられる質問
ライセンス管理で説明したタスクを参照してください。
ワークグループ エンジンは、サーバー エンジンが行うのとまったく同様にユーティリティを追跡します。各ライセンスにはユーザー カウントが明記されています。 ユーザー カウントにより、指定された数のコンピューターが、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 つ目のエンジンはファイルを開こうとしてもロック アウトします。
コンカレントを使用します。ユーザー カウントを参照してください。
ネットワークに関してよく寄せられる質問
[スタート]メニューの Pervasive グループの[ユーティリティ]から Pervasive System Analyzer を起動します。表示される初期画面で、[次へ]をクリックします。次の画面で、[アクティブ インストールをテストする]を選択して[ネットワーク通信をテストする]チェック ボックスをオンにし、その他のチェック ボックスをすべてオフにします。[次へ]をクリックします。次の画面で[詳細設定]をクリックし、テストしないプロトコルの選択をオフにして[OK]をクリックします。参照ボタン[...]をクリックして、サーバー上のインストール ディレクトリにマップしたドライブを選択します。ドライブは、マップしたドライブでなければなりません。UNC 名はサポートされません。[次へ]をクリックしてネットワーク テストを実行します。ネットワークで重大な問題があれば、結果ウィンドウで通知されます。
データ アクセスに関してよく寄せられる質問
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 では Microsoft でのリダイレクトされたマップ、または Windows 32 ビット プラットフォーム での 非表示の Admin 共有(C$)を使用したドライブ名のマップをサポートしません。
ユーザーが、ファイル サーバーへアクセスするためのオペレーティング システムの適切なログイン認証を持っているかどうかを確認してください。
Pervasive System Analyzer を実行し、[ネットワーク通信をテストする]を選択して接続が正しく行えるかどうかを確認します。
Pervasive.SQL 2000 で実行した場合、ヌル値を許可するフィールドでは、そのフィールドの開始位置に定義された追加バイトがあります。このバイトはヌル インジケーターです。次のいずれかの方法でこれを変更することができます。
SQL ステートメントを使用して新しいテーブル定義を作成する場合は SET TRUENULLCREATE=OFF というステートメントを入力します。現在のセッションではこれ以降、作成するテーブルは旧レコードの構造を使用し、ヌル値を許可する各列に余分なバイトを追加しません。
SQL ステートメントを使用しない場合は、すべての列をヌル値が許可されないようにして作成し、フィールドのサイズを取得して適切に配置することができます。
変換するファイルがリモート サーバーまたはワークグループ エンジンによって提供される場合は、以下のタスクを行うためにリモート システム上での管理者権限を持っている必要があります。また、リモート データ ファイルにマップしたネットワーク ドライブが必要です。
PCC でデータ ファイルが存在するサーバー名を右クリックし、次に[プロパティー]をクリックします。[ファイル互換性]をクリックし、[作成ファイルのバージョン]に変換するファイル バージョンを設定します。[OK]をクリックします。[はい]をクリックして、エンジンを再起動します。これらの変更によって、選択したバージョンで新しいファイルが作成されます。
[スタート]メニューから Pervasive グループの[ユーティリティ]から Maintenance ユーティリティを起動します。Maintenance ユーティリティで、[オプション|情報エディターの表示]をクリックします。[情報のロード]をクリックして、変換するデータ ファイルを選択します。[ファイルの作成]をクリックして、旧バージョン形式で作成する新しい空のデータ ファイルの名前を指定します。[OK]をクリックしてファイルを作成します。[ファイル情報エディター]ウィンドウは閉じますが、Btrieve Maintenance ユーティリティは終了しないでください。
メニューから、[データ|コピー]を選択します。ソース データ ファイル名とターゲット データファイル名(旧バージョンのファイル形式で新規に作成するファイル)を入力します。[実行]をクリックしてレコードを旧バージョンのファイルへコピーします。コピーが完了した後、新しいデータ ファイルをコピー元のファイル名と同じ名前にする必要がある場合は、元のデータ ファイルを別名で保存し、元のファイル名で新しいファイルを保存します。
ODBC および辞書ファイルに関してよく寄せられる質問
調べる方法はいくつかあります。まず、データ ファイルが置かれている場所で DDF ファイルを探します。これらが見つかれば、ほとんどの場合は ODBC を使用してデータベースにアクセスできます。DDF ファイルはデータ ファイルと異なるディレクトリに置くことができるので、PCC を使用して、アクセスするデータ ファイルのデータベースが作成されているかどうかを調べる必要もあります。また、アプリケーションでデータ ファイルのアクセスに ODBC を使用しているかどうかをアプリケーション ベンダーに尋ねることができます。
PCC で、テーブルが属するデータベースを右クリックしてから[プロパティー]をクリックします。[ディレクトリ]をクリックします。[辞書のロケーション]の値を変更します。
パスは変更されていないように見えます。変更を確認するには、X$File システム テーブルを開き、指定したユーザー テーブルの Xf$Loc フィールドを見ます。PCC にシステム テーブルが表示されていない場合は、[システム オブジェクト]を展開します。
また、SQL で ALTER TABLE USING ステートメントを使用して、特定のテーブルによって使用されるデータ ファイルを変更します。詳細については、『SQL Engine Reference』を参照してください。
常に 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 ファイルの完全なセットは 1 つの単位として考える必要があります。DDF を 1 つも持たないデータベースと別のデータベースの DDF とを混合することができます。
DDF Sniffer は、1998 年に Smithware からの権利の取得により Pervasive 製品に追加されました。現在は別個の製品としては使用できません。この機能の大半は Pervasive PSQL Control Center および DDF Builder に置き換えられました。
2 つのファイルがどのように似ているかによって答えは異なります。2 つのファイルのレコード数が違うだけなら、同じ DDF ファイルを使用することができます。フィールドまたはインデックスの数、順序、名前または型が異なれば、同じ DDF は使えません。つまり、2 つのファイルのレコード構造が完全に一致している場合にのみ同じ DDF が使用できます。
Btrieve ファイルがオーナー ネームを持つ場合、ODBC アクセスにはデータベース セキュリティを使用する必要があります。PCC でデータベース セキュリティを有効にしてください。『Advanced Operations Guide』の Pervasive PSQL エクスプローラーを使ってセキュリティをオンにするにはおよびオーナー ネームおよびセキュリティを参照してください。
注意
Master ユーザーのパスワードは忘れないでください。パスワードがないと、データベース内でセキュリティを無効にしたり管理者タスクを実行することはできません。パスワードを忘れてしまった場合に備えて、セキュリティを有効にする前に DDF をバックアップしておくこともできます。
次に、オーナー ネームを定義したデータ ファイルへの Master ユーザー アクセスを許可します。オーナー ネームを持つ各テーブルに対し、次の SQL ステートメントを発行することによってアクセスを許可することができます。
上記のステートメントを入力する場合は、変数個所をテーブルの実際の名前とそのテーブルの適切なオーナー ネームに置き換えてください。各データ ファイルは ODBC テーブルに対応していることを覚えておいてください。どのテーブルがどのデータ ファイルに対応しているかがわからない場合は、PCC を使用して見つけてください。PCC でテーブルを右クリックし、次に[プロパティー]をクリックします。ツリーで[情報]をクリックします。[テーブルの場所]フィールドは、そのテーブル定義によって参照されるファイルを示します。
セキュリティが重要な場合は、ユーザーを作成し、データベースにアクセスすると思われるすべてのユーザーに権限を割り当てます。これは、SQL で CREATE GROUP および GRANT ステートメントを使用して行います。その後、PCC でユーザーやグループを追加することができます。『Advanced Operations Guide』のユーザーとグループを参照してください。
セキュリティが重要でない場合、PUBLIC にアクセスを許可すれば、多くのユーザーの作成や権限の割り当てを行う必要がありません。PUBLIC ではネットワーク上のだれもがデータにアクセスできます。次のステートメントを使用することができます。
SQL アプリケーションをサポートする DOS リクエスターはありませんが、Windows 用の Pervasive PSQL クラインアント ソフトウェアには ODBC クライアント コンポーネントが含まれており、リモート SRDE サーバー エンジンへ接続することができます。
いいえ、ほかにも方法があります。ODBC や長年その有効性が認められている Btrieve API に加え、OLE DB プロバイダー、JDBC ドライバー、純粋な Java インターフェイス、あるいは ActiveX コントロールを使用してアプリケーションを開発できます。
ありません。Pervasive PSQL は、データを別々のファイルに保存します。リレーショナル テーブル定義ごとに 1 つのファイルとなります。データ定義、ユーザー/グループ定義などのメタ データは DDF ファイルのセットに保存されます。各 DDF ファイルの拡張子は ".ddf" です。
SRDE にはスケジューラがありません。
Btrieve 6.15 に関してよく寄せられる質問
完全な代替ツールはありませんが、Btrieve データによるレポート作成およびクエリに関しては、Xtrieve からの有効なアップグレードとして Crystal Reports for Btrieve を使用することを検討してください。
アップグレードと移行に関してよく寄せられる質問
Btrieve ファイルに含まれるファイルの構造に関する情報量は限られています。テーブル作成ウィザードでは、インデックスを使用していくつかのフィールド定義を解釈できますが、インデックスを使い果たすと、2 つ以上の実際のフィールドを含むデータ セグメントが残る場合があります。ウィザードでは内容を解析する方法がありません。レコード構造をよく理解してこれらのフィールドを分割し、レコード内のすべてのフィールドと一致するテーブル定義をビルドする必要があります。
このタスクの手順は、『Advanced Operations Guide』で説明しています。
『Getting Started with Pervasive PSQL』にはアップグレード方法の詳細な手順を説明する章があります。
その他のトピックに関してよく寄せられる質問
Btrieve の Maintenance ユーティリティを使用してレコードを保存/ダンプした場合、結果ファイルには各レコードのバイナリ イメージが含まれます。レコードが文字データで完全に構成されなければ、実際の内容を読み取ることができません。
Pervasive PSQL が ASCII の読み取り可能な形式でレコードをダンプできる唯一の方法は、DDF を読み込んで、レコードの全内容の記述を取得することです。Btrieve ではレコード長、インデックスのデータ型およびインデックスの長さのみを持ちます。Btrieve には、レコード全体の内容を解釈する方法についての情報がありません。
サーバー
デバッグ モードで実行するエンジンが置かれているコンピューターでの管理者権限を持っていなければなりません。
『Advanced Operations Guide』のトレース オペレーションの実行も参照してください。
メモ
オペレーションをトレースした後は[トレース オペレーションの実行]オプションをオフにし、[適用]をクリックします。トレース モードで Pervasive PSQL を実行した場合、パフォーマンスが低下します。
Windows クライアント
PSA ネットワーク接続テストを実行し、ネットワーク接続を確認します。アクティブ インストールのテストを参照してください。
さらに、ある種の低レベルな問題のトラブルシュートにはクライアントのトレースが使用できます。一般的に、低レベルのトレースは不要で、このようなトレースは熟練したサポート スタッフが使用するためのものです。低レベルのクライアントのトレースを実行する方法は、製品のベンダーまたは Pervasive Software のサポートが説明します。
行います。削除したレコードの領域は、以降の挿入で再利用されます。ファイル内の空き領域は、ディスクにデアロケートされることはありません。インデックス バランスがオンになっている場合は、インデックス ページ内の未使用領域も再利用されます。『Advanced Operations Guide』の Rebuild ユーティリティの概念を参照してください。
Continuous オペレーションを使えば、使用中のデータ ファイルのセットを安全にバックアップできる特別な "セーフ モード" に置くことができます。データ ファイルが Continuous オペレーション モードの間、それらのデータ ファイルは変更されず、特別なデルタ ファイルにすべてのデータベース操作の結果を保存します。バックアップが完了した後、データ ファイルは Continuous オペレーション モードから削除する必要があり、その時点のデルタ ファイルに保存された変更が使用中のファイルにロール インされます。
データ ファイルが Continuous オペレーション モード中にサーバーがダウンした場合、次回そのデータ ファイルにアクセスしたときには、データベース エンジンが既存のデルタ ファイルを検出してその時点の変更をロール インします。
データ ファイルを Continuous オペレーション モードにするには、『Advanced Operations Guide』で説明されている BUTIL -STARTBU コマンドまたは Maintenance ユーティリティを使用します。
|