以下のセクションでは、よく発生する問題をトラブルシュートおよび解決するための情報を提供します。

以下の項目は、発生する可能性がある特定の状況に対する基本的なトラブルシューティングを提供します。

または

ZenCC では、クライアント DSN なしの接続を使用してリモート サーバー データ ソース（DSN）にアクセスできます。Microsoft Excel および Access などの多くのデスクトップ アプリケーションではこれが行えません。ローカル コンピューター上でクライアント DSN を作成し、リモート サーバー DSN を使用してサーバー上のデータにアクセスできるようにします。クライアント DSN を作成するには、Windows クライアントからのクライアント アクセスの設定の手順に従ってください。最初に、アクセスするサーバー上にサーバー DSN が存在していることを確認する必要があります。

クライアントのリクエスターが初めてエンジンに接続すると、クライアントのリクエスターは内部ルーター バージョンと Btrieve Version (26) 呼び出しで返された値を比較します。クライアントのバージョンがエンジンのバージョンよりも古い場合は、クライアント システム上でダイアログ ボックスが開き、"エンジンのコンポーネントのバージョンがクライアントと異なります" というメッセージと、Zen System Analyzer（PSA）を実行するよう求める提案が表示されます。同じメッセージがクライアントの zen.log ファイルにも記録されます。

これは警告メッセージです。この状況では、クライアントはエンジンへの接続を妨げられることはありません。ただし、Actian Corporation が互換性を保証するのは、クライアントがデータベース エンジンと同じバージョンの場合のみです。このメッセージが表示されたときに、PSA の実行を行わずに古いクライアント コンポーネントを保持し、新しいクライアントをインストールした場合は、クライアントのバージョンがエンジンのバージョンと同じになるまで、製品が予期しない動作をすることが考えられます。

サーバー データにアクセスできないときは、ほとんどの場合以下のことが原因です。

以下の手順に従って、基本的な設定に問題がないかどうかを確認しながら原因を特定してください。

このような問題が起きた場合は、ZenCC の起動時に使用できるメモリを増やしてみてください。指定できるメモリ量は、お使いのマシン上にインストールされている物理メモリによってのみ制限されます。最小および最大メモリ量を指定できます。たとえば、最小および最大に 256 MB を指定するには、ZenCC を以下のコマンドで起動します。

パラメーター -vmargs は、その他のパラメーターを指定する場合に必要です。

パラメーター -Xms は ZenCC に割り当てるメモリの最小量を指定します。パラメーター -Xmx は ZenCC に割り当てるメモリの最大量を指定します。-Xms パラメーターを指定した場合は、-Xmx パラメーターも指定する必要があります。

ZenCC でデータベースを作成またはデータベースに接続しようとする場合に、いくつかの異なるメッセージを受け取ることがあります。このセクションでは、最も一般的なエラー メッセージの主な原因を説明します。

このエラーは、サーバー上に新しいデータベースを作成しようとするときに発生します。これはほとんどの場合、サーバー オペレーティング システムの管理者権限を持っていない、またサーバー上で Zen_Admin グループのメンバーでもないオペレーティング システム ユーザーとしてログインしていることが原因です。このほか、ユーザー名とパスワードを入力していなかった場合もこのエラーの原因になります。

解決方法：リモート オペレーティング システムに対するユーザー名とパスワードを入力したことを確認します。サーバー上に新しいデータベースを作成するには、サーバーでの管理者権限を持っているか、Zen_Admin グループのメンバーである必要があります。Zen_Admin グループの設定方法は、データベース エンジンの管理者権限の許可で説明しています。

Windows 32 ビット プラットフォーム の場合、ネットワーク ユーザーではなく、システム上のローカル ユーザーとして設定されていることを確認してください。ネットワーク ユーザーは、BOSTON\GILBERT のようにドメイン名と円記号（\）に続いたユーザー名を持ちます。Administrators グループまたは Zen_Admin グループのメンバーであるユーザーは、ローカル ユーザーであることを確認してください。

必要な権限を持ち、ユーザー ログインが実際に上記の条件の 1 つを満たしている場合は、次に正しいネットワークにログインしているかどうかも確認してください。ターゲット オペレーティング システムを使用していることが確実なサーバーに読み取りまたは書き込みを試行すれば、正しいネットワークにログインしているかどうか調べることができます。

ZenCC で新しいリモート サーバーを登録しようとするときに、このエラーを受け取る場合があります。このエラーが表示される場合は、いくつかの原因があります。

このエラーはほとんどの場合、オペレーティング システムのユーザー名またはパスワードを間違えてサーバーに接続しようとしていることが原因です。

ほかに考えられる原因は次のとおりです。

解決方法：ユーザー名とパスワードの綴りを再確認します。そのユーザー名とパスワードがリモート サーバーのオペレーティング システムで設定されていることを確認します。

サーバー上でのユーザーのアカウント情報を調べます。オペレーティング システムが、次回のログオン時にユーザーのパスワードの変更を要求しないことを確認します。また、そのユーザーが制限された権限を持つグループのメンバーでないようにします。

Windows 32 ビット プラットフォームの場合、ユーザーがネットワーク ユーザーではなく、システム上のローカル ユーザーとして設定されていることを確認してください。ネットワーク ユーザーは、BOSTON\GILBERT のようにドメイン名と円記号（\）に続いたユーザー名を持ちます。Administrators グループまたは Zen_Admin グループのメンバーであるユーザーは、ローカル ユーザーであることを確認してください。

ZenCC がデータベース エンジンから無効な設定プロパティを取得することは、可能性はありますが、ほとんどありません。そのようなエラー状況については、Zen テクニカル サポートにご連絡ください。

このセクションでは、お客様からよくお問い合わせのある質問にお答えします。

Demodata をデフォルトの状態に復元する方法はありますか？

インストール後によく寄せられる質問

Zen をアンインストール、または新しいバージョンの Zen をインストールした場合、以前のデータ ファイルおよび DDF がなくなることはありません。Zen System Analyzer で Zen ファイルをアーカイブに保管した場合でも、あるいは Zen ファイルと同じディレクトリにデータ ファイルがある場合でも、以前のデータ ファイルに影響はありません。

「ZenCC キャッシュをクリアする必要がある状況」を参照してください。

わからない場合は、常に「すべて」を選択してください。このオプションは、標準インストールを行います。このインストールでは問題が発生した場合にトラブルシューティングがより簡単になります。

ZenCC で、［ヘルプ］>［バージョン情報］の順に選択します。

Pervasive.SQL 2000i SP4 以降、Enterprise Server および Workgroup のエンジンはどちらもターミナル サーバー上でサポートされています。Pervasive.SQL 2000i SP3 では、サーバー エンジンがサポートされました。Pervasive.SQL 2000i SP2 では、クライアント ソフトウェアのみがサポートされました。

はい、どちらにもできます。Zen は Microsoft Failover Clustering、Microsoft Cluster Server、および Linux Heartbeat と互換性があります。『Advanced Operations Guide』の高可用性のサポートを参照してください。

これは、現時点ではサポートされません。

Zen と Btrieve 6.x を同じコンピューター上で同時に実行することはできません。

Windows のスタートアップ グループからワークグループ エンジンを削除する必要があります。スタートアップの詳細については、オペレーティング システムのドキュメントを参照してください。

ZenCC に関してよく寄せられる質問

ZenCC を起動するには、一定の要件を満たす必要があります。「Linux での ZenCC の起動」または 「macOS での Control Center の起動」を参照してください。

セキュリティに関してよく寄せられる質問

これらは初めは識別し難いように見えるかもしれませんが、規則は 1 つのみです。つまり、サーバーに既に接続できていて、データベースに直接アクセスしようとする場合にのみ、データベース ログインを使用してください。この時点に達するまでは、オペレーティング システムのログインを使用する必要があります。

たとえば、Monitor を実行してまたは設定プロパティからリモート サーバー エンジンで作業する場合は、パスワードの入力が必要です。いずれの場合でも、リモート システム上での管理者権限を持つオペレーティング システム アカウントまたは Zen_Admin のメンバーのアカウントのユーザー名とパスワードを提供する必要があります。これは、新規データベースを作成する場合にも適用されます。

データ自体で作業を始めた後で入力が必要な場合は、データベースのユーザーとパスワードを使用します。データベースのセキュリティを無効にした場合は、データベースのユーザー名とパスワードはまったく必要ありません。この場合、前の段落で述べたような管理者用のタスクを行うためのオペレーティング システムのユーザーとパスワードが必要なだけです。

Actian Zen Enterprise Server エンジンの設定は、データベース エンジン実行中のマシンへのログイン許可を持つかどうかに影響します。設定は、Zen_Admin グループを使用してもしなくても適用されます。Zen サービスの［アカウント］への［ログオン］設定を変更した場合、そのアカウントのユーザー権利ポリシーを［オペレーティング システムの一部として機能］に変更する必要があります。そうでない場合、リモート ログインは失敗します。

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

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

ユーザーの権利ポリシーを変更する手順の詳細はサービスの設定とログイン権限を参照してください。

ユーザー数に関してよく寄せられる質問

「ライセンス管理」に記載されている作業を参照してください。

同時ユーザー ライセンス モデルでは、各ライセンスにユーザー数が明記されています。ユーザー カウントにより、指定された数のコンピューターが、Zen データベース エンジンに同時に接続できます。Zen はシリアル番号によってマシンを識別するので、同じシリアル番号による接続はすべて同一マシンからのものと認識されます。たとえば、複数の NIC を持つ 1 台のマシンは同じマシンとして認識されます。

Zen にクライアント セッションとしてアクセスする各ワークステーションは、1 ユーザーとカウントされます。1 台のクライアント コンピューター上にある複数のアプリケーションは、1 ユーザーと見なされ、別個のユーザーとしてカウントされません。それぞれのターミナル サーバー セッションも 1 ユーザーとしてカウントされます。

Zen は、同じクライアント コンピューター セッションから受信する一意のプロトコルごとに 1 つのユーザー カウントを使用します。同じプロトコルで異なるアドレス形式を使用している場合は、1 ユーザーのみカウントされます。たとえば、あるアプリケーションが IPv4 を使用し、別のアプリケーションが IPv6 を使用する場合、これらのアプリケーションが同一マシン上で実行されると、1 ユーザーのみがカウントされます。IPv4 および IPv6 はそれぞれ TCP/IP の異なるアドレス形式です。

データ ファイルには、一度に 1 つのエンジンのみがアクセスを許可されています。エンジンはデータ ファイルが破損しないように排他モードでデータ ファイルを開くので、2 つ目のエンジンがファイルを開こうとしても拒否されます。

同時ユーザーを使用します。「同時ユーザー ライセンス モデル」を参照してください。

Capacity Usage ビューアーはこのような目的のために設計されています。使用するセッション数とデータ使用量のピーク値を毎日記録するので、それぞれの数量を経時的に見ることができます。この情報を使用して、必要なライセンス サイズを合理的に判断することができます。Capacity Usage ビューアーのアクセス方法および使用方法については、「Capacity Usage ビューアー」を参照してください。

ネットワークに関してよく寄せられる質問

Zen System Analyzer を起動して、初期画面で［次へ］をクリックします。次の画面で、［アクティブ インストールをテストする］を選択して［ネットワーク通信をテストする］チェック ボックスをオンにし、その他のチェック ボックスをすべてオフにします。［次へ］をクリックします。次の画面で［詳細設定］をクリックし、テストしないプロトコルの選択をオフにして［OK］をクリックします。参照ボタン［...］をクリックして、サーバー上のインストール ディレクトリにマップしたドライブを選択します。ドライブは、マップしたドライブでなければなりません。UNC 名はサポートされません。［次へ］をクリックしてネットワーク テストを実行します。ネットワークで重大な問題があれば、結果ウィンドウで通知されます。

データ アクセスに関してよく寄せられる質問

Zen System Analyzer を使用して、Btrieve または Zen の以前のバージョンのコンポーネントがすべて保持されているかどうかを確認します。次に、環境設定が正しいかどうかを確認してください。zen.log ファイルを見つけ、ステータス コード 8505 または 8517 を示すエラー メッセージがないかどうかを確認します。これらのステータス コードは、ローカルの Workgroup エンジンを使ってデータ ファイルの読み取りが試行されたことを示しています（zen.log に書き込まれるメッセージ文字列に 16 進数値が含まれる場合、その 16 進数値の前には "0x" が付くので 10 進数値と区別できます）。

ZenCC を起動します。ローカル クライアントを右クリックし、［プロパティ］を選択します。［アクセス］をクリックします。［ローカル MicroKernel エンジンの使用］オプションのチェックがオフで、［リモート MicroKernel エンジンの使用］オプションのチェックがオンになっていることを確認してください。

ファイルはどのように共有していますか？Zen では Microsoft でのリダイレクトされたマップ、または Windows 32 ビット プラットフォームでの 非表示の Admin 共有（C$）を使用したドライブ名のマップをサポートしません。

ユーザーが、ファイル サーバーへアクセスするためのオペレーティング システムの適切なログイン認証を持っているかどうかを確認してください。

Zen System Analyzer を実行し、［ネットワーク通信をテストする］を選択して接続が正しく行えるかどうかを確認します。

Pervasive.SQL 2000 で実行した場合、ヌル値を許可するフィールドでは、そのフィールドの開始位置に定義された追加バイトがあります。このバイトはヌル インジケーターです。次のいずれかの方法でこれを変更することができます。

SQL ステートメントを使用して新しいテーブル定義を作成する場合は SET TRUENULLCREATE=OFF というステートメントを入力します。現在のセッションではこれ以降、作成するテーブルは旧レコードの構造を使用し、ヌル値を許可する各列に余分なバイトを追加しません。

SQL ステートメントを使用しない場合は、すべての列をヌル値が許可されないようにして作成し、フィールドのサイズを取得して適切に配置することができます。

変換するファイルがリモート Enterprise Server、Cloud Server、または Workgroup エンジンによって提供される場合は、以下のタスクを行うためにリモート システム上での管理者権限を持っている必要があります。また、リモート データ ファイルにマップしたネットワーク ドライブが必要です。

ZenCC でデータ ファイルが存在するサーバー名を右クリックし、［プロパティ］を選択します。［ファイル互換性］をクリックし、［作成ファイルのバージョン］に変換するファイル バージョンを設定します。［OK］をクリックします。［はい］をクリックして、エンジンを再起動します。これらの変更によって、選択したバージョンで新しいファイルが作成されます。

Maintenance ユーティリティを実行して、［オプション］メニューから［情報エディターの表示］を選択します。［情報のロード］をクリックして、変換するデータ ファイルを選択します。［ファイルの作成］をクリックして、旧バージョン形式で作成する新しい空のデータ ファイルの名前を指定します。［OK］をクリックしてファイルを作成します。［ファイル情報エディター］ウィンドウは閉じますが、Btrieve Maintenance ユーティリティは終了しないでください。

メニューから、［データ］>［コピー］を選択します。ソース データ ファイル名とターゲット データファイル名（旧バージョンのファイル形式で新規に作成するファイル）を入力します。［実行］をクリックしてレコードを旧バージョンのファイルへコピーします。コピーが完了した後、新しいデータ ファイルをコピー元のファイル名と同じ名前にする必要がある場合は、元のデータ ファイルを別名で保存し、元のファイル名で新しいファイルを保存します。

ODBC および辞書ファイルに関してよく寄せられる質問

調べる方法はいくつかあります。まず、データ ファイルが置かれている場所で DDF ファイルを探します。これらが見つかれば、ほとんどの場合は ODBC を使用してデータベースにアクセスできます。DDF ファイルはデータ ファイルと異なるディレクトリに置くことができるので、ZenCC を使用して、アクセスするデータ ファイルのデータベースが作成されているかどうかを調べる必要もあります。また、アプリケーションでデータ ファイルのアクセスに ODBC を使用しているかどうかをアプリケーション ベンダーに尋ねることができます。

ZenCC でテーブルのデータベースを右クリックし、［プロパティ］を選択します。［ディレクトリ］をクリックします。［辞書のロケーション］の値を変更します。

パスは変更されていないように見えます。変更を確認するには、X$File システム テーブルを開き、指定したユーザー テーブルの Xf$Loc フィールドを見ます。ZenCC にシステム テーブルが表示されていない場合は、［システム オブジェクト］を展開します。

また、SQL で ALTER TABLE USING ステートメントを使用して、特定のテーブルによって使用されるデータ ファイルを変更します。詳細については、『SQL Engine Reference』を参照してください。

常に DDF のバックアップ コピーを行ってください。ランタイム DDF を変更するときには、必ず変更前にその DDF のバックアップ コピーを行ってください。最初にデータベースのセキュリティを有効にする場合は、セキュリティなしの辞書のバックアップ コピーと、セキュリティ付きの辞書のバックアップ コピーを行います。

Btrieve ユーティリティで編集できる場合、その DDF は標準の辞書ファイルではありません。標準の辞書ファイルは、Btrieve で直接アクセスすることができません。このロック アウトは、リレーショナル エンジンのみが辞書へ書き込みできることを保証する安全な機能です。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 が存在しないものがあります。このような辞書は、Zen 製品で動作しません。たとえば、file.ddf ではなく x$file.ddf というファイルがある場合は、その DDF は非標準であることがわかります。

非標準の DDF は通常、ZenCC や PSQL リレーショナル エンジンで正しく動作しません。

DDF ファイルの完全なセットは 1 つの単位として考える必要があります。DDF を 1 つも持たないデータベースと別のデータベースの DDF とを混合することができます。

DDF Sniffer は、1998 年に Smithware 社からの権利の取得により Zen に追加されました。現在は独立した製品としては使用できません。DDF Sniffer の機能は ZenCC と DDF Builder に統合されました。

2 つのファイルがどのように似ているかによって答えは異なります。2 つのファイルのレコード数が違うだけなら、同じ DDF ファイルを使用することができます。フィールドまたはインデックスの数、順序、名前または型が異なれば、同じ DDF は使えません。つまり、2 つのファイルのレコード構造が完全に一致している場合にのみ同じ DDF が使用できます。

Btrieve ファイルがオーナー ネームを持つ場合、ODBC アクセスにはデータベース セキュリティを使用する必要があります。ZenCC でデータベース セキュリティを有効にしてください。『Advanced Operations Guide』の 「Zen エクスプローラーを使用してセキュリティを有効にするには」および「オーナー ネームおよび SQL アクセス」を参照してください。

次に、オーナー ネームを定義したデータ ファイルへの Master ユーザー アクセスを許可します。オーナー ネームを持つ各テーブルに対し、次の SQL ステートメントを発行することによってアクセスを許可することができます。

上記のステートメントを入力する場合は、変数個所をテーブルの実際の名前とそのテーブルの適切なオーナー ネームに置き換えてください。各データ ファイルは ODBC テーブルに対応していることを覚えておいてください。どのテーブルがどのデータ ファイルに対応しているかがわからない場合は、ZenCC を使用して見つけてください。ZenCC 内でテーブルを右クリックし、［プロパティ］を選択します。ツリーで［情報］をクリックします。［テーブルの場所］フィールドは、そのテーブル定義によって参照されるファイルを示します。

セキュリティが重要な場合は、ユーザーを作成し、データベースにアクセスすると思われるすべてのユーザーに権限を割り当てます。これは、SQL で CREATE GROUP および GRANT ステートメントを使用して行います。その後、ZenCC でユーザーやグループを追加することができます。『Advanced Operations Guide』の「ユーザーとグループ」を参照してください。

セキュリティが重要でない場合、PUBLIC にアクセスを許可すれば、多くのユーザーの作成や権限の割り当てを行う必要がありません。PUBLIC ではネットワーク上のだれもがデータにアクセスできます。次のステートメントを使用することができます。

SQL アプリケーションをサポートする DOS リクエスターはありませんが、Windows 用の Zen クラインアント ソフトウェアには ODBC クライアント コンポーネントが含まれており、リモート サーバー エンジンへ接続することができます。

いいえ、ほかにも方法があります。ODBC や長年その有効性が認められている Btrieve API に加え、OLE DB プロバイダー、JDBC ドライバー、純粋な Java インターフェイス、あるいは ActiveX コントロールを使用してアプリケーションを開発できます。

ありません。Zen は、データを別々のファイルに保存します。リレーショナル テーブル定義ごとに 1 つのファイルとなります。データ定義、ユーザー/グループ定義などのメタ データは、DDF ファイルに保存されます。各 DDF ファイルの拡張子は ".ddf" です。

リレーショナル エンジンにはスケジューラがありません。

アップグレードと移行に関してよく寄せられる質問

Btrieve ファイルに含まれるファイル構造に関する情報量は限られています。テーブル作成ウィザードでは、ファイルのインデックスからいくつかのフィールド定義を取得できますが、取得後も、2 つ以上の実際のフィールドを含むデータ セグメントが残る場合があります。ウィザードでは内容を解析する方法がありません。レコード構造を自身で理解してこれらのフィールドを分割し、レコード内のすべてのフィールドと一致するテーブル定義をビルドする必要があります。

その他のトピックに関してよく寄せられる質問

Btrieve の Maintenance ユーティリティを使用してレコードを保存またはダンプした場合、結果ファイルには各レコードのバイナリ イメージが含まれます。レコードが文字データで完全に構成されなければ、実際の内容を読み取ることができません。

Zen が ASCII の読み取り可能な形式でレコードをダンプできる唯一の方法は、DDF を読み取って、レコードの仕様全体を取得することです。Btrieve ではレコード長、インデックスのデータ型およびインデックスの長さのみを持ちます。Btrieve は、これら以外のレコード内容を解析するための情報を持ちません。

はい、Windows で Enterprise Server、Cloud Server、または Client を使用している場合には実行できます。

エンジンをデバッグ モードで実行するには、実行するシステムの管理者権限が必要です。

エンジンを再起動する必要はありません。

『Advanced Operations Guide』の「トレース オペレーションの実行」も参照してください。

PSA ネットワーク接続テストを実行し、ネットワーク接続を確認します。「アクティブ インストールのテスト」を参照してください。

さらに、ある種の低レベルな問題のトラブルシュートにはクライアントのトレースが使用できます。一般的に、低レベルのトレースは不要で、このようなトレースは熟練したサポート スタッフが使用するためのものです。低レベルのクライアントのトレースを実行する方法は、製品のベンダーまたは Actian のテクニカル サポートが説明します。

行います。削除したレコードの領域は、以降の挿入で再利用されます。ファイル内の空き領域は、ディスクにデアロケートされることはありません。インデックス バランスがオンになっている場合は、インデックス ページ内の未使用領域も再利用されます。『Advanced Operations Guide』の 「Rebuild ツールの概念」を参照してください。

Continuous オペレーションを使えば、使用中のデータ ファイルのセットを安全にバックアップできる特別な "セーフ モード" に置くことができます。データ ファイルが Continuous オペレーション モードの間、それらのデータ ファイルは変更されず、特別なデルタ ファイルにすべてのデータベース操作の結果を保存します。バックアップが完了した後、データ ファイルは Continuous オペレーション モードから削除する必要があり、その時点のデルタ ファイルに保存された変更が使用中のファイルにロール インされます。

データ ファイルが Continuous オペレーション モード中にサーバーがダウンした場合、次回そのデータ ファイルにアクセスしたときには、データベース エンジンが既存のデルタ ファイルを検出してその時点の変更をロール インします。

データ ファイルを Continuous オペレーション モードにするには、『Advanced Operations Guide』で説明されている BUTIL -STARTBU コマンドまたは Maintenance ユーティリティを使用します。