Zen Control Center（ZenCC）はデータベースの作成および管理や、データベース エンジンの制御を行うためのグラフィカル ツールです。ここから本製品のほとんどすべての機能にアクセスすることができます。この章では、ZenCC のインターフェイスおよび一般的な操作について説明します。

Zen Control Center は、Zen エンジンへの接続、データベースとテーブルの設定や変更、データのクエリや更新、エンジンのパフォーマンス調整、および Zen ドキュメント ライブラリへのアクセスを行うための、統合されたフレームワークです。

ZenCC では Zen エクスプローラーと呼ばれる、オブジェクト ツリー形式のファイル エクスプローラーを使用します。このツリーは、展開すると詳細を表示します。オブジェクトには、エンジン、データベース、テーブル、ユーザー設定などがあります。次の図は、いくつかのタブ付き表示された ZenCC を示します。Zen エクスプローラーは左側に配置されています。

Linux ディストリビューションに応じて、あるいは Mac OS を使用している場合、ZenCC（画面の）表示が異なる場合がありますが、機能は同一です。

Windows プラットフォームでは、ZenCC はデータベース エンジンまたはクライアントのインストール時にデフォルトでインストールされます。『Getting Started with Zen』の Zen のオプション機能を参照してください。

Linux および macOS では、ZenCC は完全インストールに含まれます。『Getting Started with Zen』の Linux、macOS および Raspbian におけるフル インストールとクライアント インストールを参照してください。

オペレーティング システムの［スタート］メニューまたはアプリ画面から Control Center にアクセスします。実行可能ファイル zencc.exe を実行することもできます。

コマンド プロンプトから実行可能スクリプト ファイル zencc を実行して ZenCC を起動します。このスクリプト ファイルは、デフォルトで usr/local/actianzen/bin にインストールされます。

ファイル ブラウザーでスクリプト ファイルをダブルクリックするのではなく、コマンド プロンプトから ZenCC を起動することをお勧めします。ZenCC の実行に関するトラブルシューティング ガイドを参照してください。

Linux 上で ZenCC を起動するには、以下の条件に合致する必要があります。

ZenCC を実行する要件に合致しているのに、実行に問題がある場合は、以下のトラブルシューティング ガイドを参考にしてください。

macOS では、デスクトップにログインしているユーザーのみが ZenCC を起動することができます。Finder を開き、［Applications］>［Actian Zen］>［Zen Control Center］の順に開きます。

効率のため、ZenCC により特定の情報がキャッシュされます。キャッシュは、ZenCC と相互作用する製品をインストールまたはアップグレードした後でクリアする必要があります。これは、インストールまたはアップグレードによる変更内容が Zen エクスプローラーに反映されるようにするためです。たとえば、DataExchange をインストールまたはアップグレードする場合、ZenCC キャッシュをクリアする必要があります。

キャッシュは、ZenCC をパラメーターを使ってコマンド ラインから起動した場合にのみクリアできます。

ZenCC のメイン ウィンドウには、以下のエディターとビューが含まれます。

さまざまなエディターおよびビューを使用してオブジェクトを表示および操作することができます。同じ種類の複数のエディター（たとえば、SQL Editor）を同時に開くことができます。編集中の各オブジェクトは、エディター上部にタブによって示されます。タブにはオブジェクトの名前が表示されます。エディターで変更したデータは、明示的に保存する必要があります（たとえば、［ファイル］>［上書き保存］を使用）。

Zen エクスプローラーのようなビューは、一度に 1 つしか開けません。ビュー内で実行された操作は、保存していない場合でも、直ちに適用されます。

以下の表にエディターとビューの特性をまとめます。

このビューでは、複数の種類のオブジェクトをツリー形式で表示し、さまざまな作業が行えます。

オブジェクトのツリーには Zen という名前のルート ノードがあります。ルート ノードにあるのは、クライアント、サービス、データベース エンジン、データベース、テーブル、ビュー、ストアド プロシージャ、ユーザー定義関数、トリガー、グループ、ユーザー、およびシステム オブジェクト（システム テーブルなど）です。

Zen エクスプローラー内のほとんどのオブジェクトは、展開して詳細を表示することができます。下位のオブジェクトを表示するには、オブジェクトの左にある展開アイコンをクリックします。この折りたたみアイコンは展開アイコンをクリックすると切り替わって表示されます。下位オブジェクトを非表示にするには、折りたたみアイコン（"－" 記号など）をクリックします。

オブジェクトに構成できる設定がある場合は、そのオブジェクトを右クリックして［プロパティ］を選択します。また、オブジェクトをクリックしてから Alt+Enter キーを押してプロパティを表示することもできます。『Advanced Operations Guide』の「設定リファレンス」も参照してください。

プロパティへのアクセス以外にも、オブジェクトの右クリックによって Zen エクスプローラーからは多くのタスクを実行することができます。次の表ではそれらのタスクについて簡単に説明します。

SQL Editor を使用すると、Zen データベースに対し、SQL（構造化問い合わせ言語）ステートメントを実行することができます。詳しい説明については、「SQL Editor」 を参照してください。

グリッド ウィンドウは、スプレッドシートのような行列形式で SQL ステートメントの実行結果を表示します。各フィールドは列として示され、データは列内のセルに表示されます。グリッド セル内でデータを直接変更することができるだけでなく、グリッドに行を追加することもできます。

Table Editor と SQL Editor は、共にグリッドを使用します。詳細については、「Table Editor を使ってテーブル データを表示するには」および「グリッド ウィンドウ ビュー」を参照してください。

テキスト ウィンドウ ビューは、テキスト形式で SQL ステートメントの実行結果を表示します。テキストは表示のみです。テキストを変更してデータ値を変更することはできませんが、テキストをコピーすることはできます。詳しい説明については、「テキスト ウィンドウ ビュー」を参照してください。

アウトライン ウィンドウを使用すると、SQL ステートメントをツリー構造で表示することができます。ツリーのルート ノードは SQL Editor ウィンドウ ビューと同じ名前です。詳しい説明については、「アウトライン ウィンドウ ビュー」を参照してください。

エディターがアウトラインをサポートしていない場合はアウトライン ウィンドウは利用できないので注意してください。現在、SQL Editor のみがアウトライン ビューをサポートしています。

Table Editor を使用すると、テーブルの列の追加、削除または特性の変更を行うことができます。このテーブルは、新規作成したものか、または編集したい既存のテーブルです。詳しい説明については、「Table Editor」 を参照してください。

ZenCC で全般の初期設定を行うことができます。ZenCC のウィンドウ ビューや外部ツールの初期設定を行うこともできます。

全般の初期設定で指定できるオプションは、以下のとおりです。

［関連付けられている DSN エントリは常に削除されます。］を選択して、データベースのすべての DSN エントリがプロンプトなしでデータベースと一緒に削除されるようにします。

［SQL ドキュメントを開くたびに、新しいデータベースの入力を求めるダイアログを表示しない。］の選択を解除すると、SQL Editor で SQL ドキュメントを開くたびにデータベースの選択を求められます。このオプションが選択されていない場合は、これを選択して、SQL ドキュメントを開いたときに最近選択したデータベースを使用するようにします。選択されたデータベースは、ZenCC のセッション間で保持されることはありません。ZenCC を閉じて再度開いた場合は、新しいデフォルトのデータベース コンテキストを選択する必要があります。

以下の ZenCC ウィンドウ ビューの初期設定を行うことができます。

ファイル エンコードの初期設定によって、ワイド文字データを含むファイルの作業をより簡単に行うことができるようになりました。この初期設定には以下の機能があります。

一部のユーティリティは、ZenCC インターフェイスと完全に統合されていません。ただし、以下のユーティリティは［ツール］メニューから選択することによって ZenCC 内から起動することができます。

Windows 環境では、ZenCC の［ツール］メニューを他のアプリケーションで拡張することができます。追加した項目は、［ツール］メニューのリストの最後に表示されます。

ZenCC を使用すると、Windows コントロール パネルのサービス アプリケーションを使用することなく、Zen Server を Windows システムで操作できます。ZenCC から開始、停止、および開始時の設定を行うことができます。

データベース エンジン以外の Zen 製品もサービスとして実行できます。これらのサービスは、Actian Zen Enterprise Server エンジンのサービスから独立しています。詳細についてはサービスの依存関係を参照してください。

『Advanced Operations Guide』の 「ZenCC でサービスの起動ポリシーを設定するには」を参照してください。

ZenCC を使用して、ローカル マシン上のデータベース エンジンまたはリモート サーバー エンジンを操作することができます。リモート サーバー エンジンで動作するには、ZenCC に通知する必要があります。この手順を、サーバーの「登録」と言います。

ローカル サーバーは、Zen をインストールしたときに、自動的に ZenCC へ登録されます。ローカル サーバーは Zen エクスプローラーのエンジン ノードの下の最初のエントリとして表示されます。

データベース エンジンとクライアントの設定を参照してください。

ZenCC では、すべてのデータベース エンジンの同時セッション数とデータ使用量を監視する Capacity Usage ビューアーを提供します。このビューアーは特に、異なるライセンス モデルを使用する Zen エンジンへの移行を検討する際に役立ちます。

『Advanced Operations Guide』の 「Capacity Usage ビューアー」を参照してください。

ZenCC ではデータベース エンジンの特定の動作と属性を監視することができる Monitor ユーティリティを組み込んでいます。このユーティリティは MicroKernel エンジンおよびリレーショナル エンジンの状況も監視できます。監視情報は一連のタブ構成で表されます。タブの配置は必要に応じて変えることができます。タブ内のデータ列も配置を変えたり並べ替えたりすることができます。ある特定の時点のスナップショットを表示し、その情報は手動または自動でリフレッシュすることができます。

『Advanced Operations Guide』の「データベースの状態の監視」を参照してください。

ZenCC で提供される Defragmenter ユーティリティによって、エンジンのパフォーマンスを低下させる恐れのある、データ ファイルの断片化を検出することができます。また、Defragmenter では、順序が正しくないレコードを再配置したり、データの削除によって空いた領域を取り除くことで、断片化を修正することもできます。ファイルの最適化によってそのファイルのデータが変更されることはありません。また、ファイルの最適化中でもレコードの作成、読み取り、更新または削除が可能です。ほとんどの場合、Defragmenter の機能を使用するためにダウンタイムを設ける、または業務を停止する必要はなく、データベース エンジンの実行中にもこの機能を使用することができます。

『Advanced Operations Guide』の「データ ファイルの断片化の監視」を参照してください。

データベースは、まとめて格納されているデータの集合です。新しく作成されたデータベースは空で、テーブルを伴っています。詳しい説明については、『Advanced Operations Guide』の 「Zen データベース」を参照してください。

データベースのプロパティには、ファイルの場所、参照整合性、セキュリティおよびデータベースがバインドされているかどうかなどの項目が含まれます。

データベースのプロパティは、ZenCC 内のプロパティ ダイアログ ボックスから設定します。このウィンドウでは次のプロパティ ノードが表示されます。

このセクションでは、コード ページのプロパティ設定について説明します。

このプロパティは、メタデータで使用するエンコードを指定し、DBNAMES.cfg に格納されます。このプロパティはデータベースに適用されます。つまり、データベースとデータをやり取りするすべてのクライアント アプリケーションに影響する可能性があります。Zen データベース エンジンとクライアント アプリケーション間で互換性のあるエンコードを確立する必要があります。これを行うさまざまな方法については、『Advanced Operations Guide』のデータベース コード ページとクライアント エンコードを参照してください。

データベース コード ページは、特に、異なる OS エンコードを使用して Zen DDF を手動で別のプラットフォームへコピーしながら、データベース エンジンにメタデータを正しく変換させたい場合に役立ちます。

デフォルトのコード ページは "サーバーのデフォルト" で、データベース エンジン実行中のサーバーのオペレーティング システム コード ページを意味します。"コード ページの変更" では設定に関する追加情報を提供し、特定のコード ページを選択することができます。ただし、"コード ページの変更" が行えるのは Linux 版のみです。

ZenCC それ自体はデータベース エンジンのクライアント アプリケーションです。クライアントとして、各データベース セッションでメタデータおよびデータを読み取りまたは挿入する際に使用するコード ページを指定することができます。既存データベースのデフォルトでは、ZenCC が実行されているマシンのエンコードを使用します。これは旧来の動作です。新しいデータベースのデフォルトでは、自動変換を使用します。

次の表では、［ZenCC 接続エンコード］と［データベース コード ページ］の設定の相互の影響を説明します。

データベース内に OEM 文字データがある場合、旧来の解決法は DSN を使用する ODBC のようなアクセス方法を使用して OEM/ANSI 変換を指定することでした。このバージョンでは、データベースに OEM コード ページを設定し、アクセス方法で自動変換を使用することが可能になりました。『ODBC Guide』の「自動」も参照してください。

このディレクトリのプロパティ設定は、一定のタイプのファイルが存在する物理ストレージ上の場所を指定します。

この場所は、辞書ファイル（DDF）が存在する物理的な保管場所を指定します。この場所は、接続しているサーバーと同じサーバーで、データベース エンジンが実行されているサーバーにある必要があります。場所の形式は、サーバー マシンで直接作業しているような形式にする必要があります。

たとえば、データベース エンジンを実行中の Windows サーバーに接続しているワークステーションを使用していて、サーバーの C:\ ドライブの mydata フォルダーに新規データベースを作成したいとすると、ロケーションに「c:\mydata」と入力します。サーバーの C:\ ドライブをローカル ネットワーク ドライブ（たとえば、F:\）にマップしていたとしても、このように入力します。

［データ ディレクトリ］フィールドのリストでは、データ ファイルが存在する物理ストレージ上の場所を指定します。［新規作成］をクリックして新規リソースを追加します。［除去］をクリックすると、データ ファイルの場所をリストから削除することができます。データ ファイルの場所は、データベース エンジンが起動している同じサーバー上でなければなりません。

［辞書のロケーション］についても同じ方法で場所を指定してください。

［全般の設定］には次のプロパティ設定が含まれています。

データベースが、バインドされているかどうかを示します。データベースをバインドすると、DDF またはデータ ファイルが別のデータベースによって使用されることを防ぎ、データ ファイルが同一データベース内で複数のテーブル定義を持つことを防ぎます。

バウンド データベースの詳細については、バウンド データベースと整合性の設定を参照してください。

データベースにセキュリティ、RI、トリガーなどの整合性制約を設定するかどうかを指定します。これらの制約は、データ ファイルへの ODBC/SQL アクセスだけでなく、Btrieve アクセスにも適用されます。

参照整合性の設定および Btrieve およびリレーショナル制約間の相互作用を参照してください。

このプロパティは読み取り専用で、データベースが作成されたときにメタデータ バージョン 2 が設定されたかどうかを示します。"長いメタデータ" はメタデータ バージョン 2 の別称です。

［リレーショナル制約］には、データベースに効力のあるリレーショナル制約が行列形式で一覧表示されます。Btrieve およびリレーショナル制約間の相互作用を参照してください。

［セキュリティ］には、［データベース セキュリティ］タブおよび［Btrieve セキュリティ］タブにそれぞれのプロパティ設定が含まれています。セキュリティの完全な説明については、「Zen セキュリティ」を参照してください。

新規データベースを作成するには、ZenCC 内にある次のダイアログを使用します。ダイアログの下にある表ではその GUI オブジェクトについて説明しています。（新規データベースを作成するにはも参照してください。）

ダイアログ イメージ内の項目をクリックすると、その項目の使用に関する情報を確認できます。

データベースに関連する作業は次のとおりです。

名前付きデータベースの概念については、『Advanced Operations Guide』の 「Zen データベースの概念」を参照してください。

現在ログインしているデータベースを削除することはできません。データベース エンジンからログアウトするにはを参照してください。

データベース セキュリティが "混合" または "データベース" に設定されている場合は、セキュリティを解除した後にデータベースを削除できるようになります。Zen エクスプローラーを使用してセキュリティを無効にするにはおよび SQL を使用してセキュリティを無効にするにはを参照してください。

データベースを削除する際に、関連付けられている DSN を一緒に削除する場合は、［ウィンドウ］>［設定］>［Zen］>［全般の設定］から、［関連付けられている DSN エントリは常に削除されます。］オプションを選択します。

あるデータベースのテーブル（データ ファイル）を、新規作成した別名のデータベースで使用しようとすると、その新しいデータベース用としてテーブルを開くことができないことがあります。場合によっては、そのテーブルは元のバインドされているデータベース名を持っている可能性があります。たとえば、元のデータベースで、バインドが設定されている、または参照整合性が設定されていると、データ ファイルはその元のデータベース名にバインドされます。バウンド データベースと整合性の設定も参照してください。

新しいデータベース用にそれらのテーブルを開くことができるようにするには、その新しいデータベースのデータベース名を修復する必要があります。修復を行うと、テーブルは新しいデータベースと関連付けられます。

テーブルは、データベースがデータを保存するオブジェクトです。Zen では、データ テーブルとシステム テーブルの 2 種類のテーブルを扱います。データ テーブルはユーザーによって作成されます。テーブルは作成後、それにデータを入れるまでは空です。システム テーブルは、必要に応じて Zen データベースによって作成され、データが入れられます。

データ テーブルの完全な説明については、「Table Editor」 を参照してください。また、そのセクションでは、テーブルの作成と削除、および列や外部キーなどの操作についても説明されています。

システム テーブルは Zen エクスプローラーのシステム オブジェクト ノードの下に表示されます。その内容は、テーブルのプロパティを表示するにはに説明されているので、ご確認いただけます。

テーブル プロパティは、テーブルに関する情報を提供します。別個のタブにより、全般的なプロパティ、列の情報、およびインデックスの情報が表示できます。［全般］タブで一覧できるプロパティについて、次の表で説明します。

スキーマは、メタデータ、つまりデータに関するデータです。Zen を Btrieve トランザクショナル データベースとして使用する場合、明示的なスキーマは必要ありませんが、少量のメタデータが Btrieve ファイル自体に格納されるほか、MicroKernel エンジンの実行時は MicroKernel エンジンの中に格納されます。これに対し、Zen リレーショナル データベースでは、データを保管および管理するのに使用されるすべての情報はスキーマに格納されます。このリレーショナル情報はデータ辞書ファイル（DDF）に格納されます。本 SQL エンジンが正しく動作し、かつ高いパフォーマンスを発揮するかどうかは、DDF が有効かつ正確であるかどうかによって決まります。このセクションの情報を使用することで、無効または不完全な DDF を検出し、そのような DDF を修正するために実行できる処置を決定することができます。

DDF では、テーブルおよびフィールドの構造と以下の特性/機能を定義します。

スキーマは再利用や保管のためにファイルにエクスポートすることができます。ZenCC で、データベースを右クリックし、［スキーマのエクスポート］を選択すると、データベース スキーマのエクスポート ウィザードが表示されます。テーブルを右クリックして［テーブル スキーマのエクスポート］を選択すると、ダイアログが表示されます。どちらの場合も、ファイル拡張子 .sql とする、スキーマがエクスポートされたファイルを作成します。このファイルは SQL スクリプトと呼ばれます。デフォルトのエクスポート場所は、C:\Users\<ユーザー アカウント> です。

エクスポートによって作成された SQL スクリプトは、次の方法で使用できます。

このセクションの残り部分では、以下の項目について説明します。

データベース スキーマのエクスポート ウィザードには、Zen のメタデータをエクスポートするための以下のような設定が用意されています。

［テーブル スキーマのエクスポート］ダイアログには、テーブルのメタデータをエクスポートするための以下のようなオプションが用意されています。

以下は IN DICTIONARY 句の使用例を示しています。

このオプションを選択する場合は、必ずすべてのデータ ファイルを新しいデータベースの場所にコピーしたうえで、その新しい場所でスクリプトを実行してください。データ ファイルは、テーブル作成の成功に必要不可欠です。詳細については、『SQL Engine Reference』の 「IN DICTIONARY」 を参照してください。

以下の手順では、ZenCC を使ってデータベース スキーマをエクスポートしたりインポートしたりする方法を示します。

スキーマで使用するデータ ファイルをコピーしたら、それらのファイルを必ず新しい場所に置いてから、スキーマをインポートしてください。また、スキーマをインポートする際には、必ず IN DICTIONARY オプションを指定してください。

テーブルのデータ ファイルがコピーされている場合は、そのファイルを必ず新しい場所に置いてから、スキーマをインポートしてください。また、スキーマをインポートする際には、必ず IN DICTIONARY オプションを指定してください。

このセクションでは、 データベース スキーマの一般的な使用法について説明します。

データベース スキーマをインポートすることで、エクスポート元のデータベースの完全コピーを作成できます。このようなコピーは、テストを行ったり、アプリケーション配布の一環として実行時にメタデータを生成したりするために使用できます。

機密性のため、テクニカル サポートがデータ ファイルを共有できないようになっているなどのシナリオでは、スキーマのインポートにより DDF と空のファイルが作成されるよう、データ ファイルのコピーをスキップすることができます。

v1 形式から v2 形式にデータベースを移行すると、長い識別子名、ビューおよびストアド プロシージャの実行権限、データベース オブジェクトの最大数の拡張など v2 メタデータの機能をお使いのアプリケーションと環境で利用できるようになります。

v1 形式から v2 形式にデータベースを移行する手順は、データベースをコピーする場合と似ていますが、相違点は、新しいデータベースを作成する際に長いメタデータ オプションを選択する必要があることです。

v1 形式から v2 形式への移行を行う際は、v2 データベースをその基となった v1 と比較する検証手順を実行する必要があります。検証に成功した場合は、新データベースでも旧データベースと同じ動作を期待できることになります。

多くのお客様は 20 ～ 30 年の長きにわたって Zen データベースをお使いです。スキーマは、レガシー ツールやサード パーティ製のユーティリティを使用して、あるいは手書きによって作成されている可能性があります。このようなデータベースには、無効なテーブル定義があったり、データ ファイルに一致しない定義があったりします。エクスポートおよびインポート処理では、このような欠陥のある定義が検出されるので、それらの定義を修正することで、Zen エンジンの機能およびパフォーマンスを最適化することができます。

エクスポート操作を行うには、CREATE データベース権限が付与されたグループのユーザー アカウントが必要です。スキーマをエクスポートする前に、そのようなアカウントでログインするか、そのようなアカウントのユーザー名とパスワードを入力するよう求められることを考慮しておきます。

Zen では 1 つのデータ ファイルに対して複数のテーブル定義を作成できます。たとえば、1 つ目の定義には、データ ファイルの最初のキーに対応する最初の列を ID CHAR(12) として指定できる一方、2 つ目のテーブル定義では、12 文字の ID を小さな列、SequenceNum CHAR(8)、Location CHAR(2)、Zone CHAR(2) の集合として管理できます。Zen では、USING 句を使って同じデータ ファイルを参照することで、複数のテーブル定義を作成できます。ただし、次の例に示すように、定義同士が両立可能である必要があります。

また、Zen では、各エントリにレコード型を示す列を追加することで、同じデータ ファイルにさまざまなレコード レイアウトを格納できます。このようなファイルはバリアント レコードがあると呼ばれます。次に例を示します。

Vendor テーブルと Customer テーブルはともに company.dat を参照し、両テーブルの定義の最初の 2 つの列は一致していますが、3 つ目以降の列定義は異なっています。これらのテーブルの 2 つのレコード レイアウトは、全体の長さが同じで、かつデータ ファイル内のレコード長も一致している必要があります。テーブル定義には、全体の長さとなるように埋め込むための余分なフィールドも必要なら追加できます。さらに、すべてのバリアント レコードに共通するインデックス定義があるほか、ただ 1 つのテーブル定義で使用されるインデックスもあります。この例では、company.dat にアクセスするアプリケーションは、各レコードのテーブル定義を指定するための正しい RecType 値を送信する必要があります。

データ ファイル内のテーブル定義数が［スキーマのエクスポート］機能によりチェックされます。複数個見つかった場合は、CREATE TABLE ステートメントと、2 つのほとんど同じ CREATE INDEX ステートメント（IN DICTIONARY を一方は含み、他方は含まない点のみが異なる）を使って、スキーマがエクスポートされます。

これら追加の CREATE INDEX ステートメントを使ってスキーマをインポートすると、各テーブルに対して、共通のインデックスと一意のインデックスがともに正常に作成されます。インポートを行うときに、いくつかのタイプのメッセージが記録されます。これらのメッセージはエラーまたは警告としてマークされますが、通常は無視できます。この理由について、Vendor および Customer テーブルで共有される サンプル データ ファイル company.dat を引き続き使った次の例で説明します。これらのテーブルのスキーマを新しいデータベースにインポートすると、以下の現象が発生します。

同じデータ ファイルを使用するバリアント テーブルを操作していることがわかっている場合は、このようなインポート ログ エントリは無視できます。スキーマのインポート ログの検証セクションにこれら以外のエラーまたは警告が出力されていない場合は、テーブルが正しく作成されたことが公式に確定します。

データベース スキーマのエクスポートとインポートは、SQL アプリケーションでの予期しない結果や不正な結果を生じ得るメタデータ定義の問題を検出するのに役立ちます。このような問題は通常、標準的な SQL に準拠していない DDF によって発生します。スキーマをエクスポート、インポート、および検証したときに記録された警告メッセージやエラー メッセージを使って、スキーマ定義を評価、修正することができます。

トラブルシューティング処理では、以下の一部または全部を確認、分析するなど、いくつかのステップを実行する場合があります。

このセクションでは、重要なログ エントリの詳細および例、ならびに実行すべきアクションを示します。

スキーマをエクスポートすると、Zen はデータベースに定義されているオブジェクトごとに SQL ステートメントを生成しようとします。問題のあるオブジェクトについては、調査が必要な潜在的な問題に関する洞察に満ちたメッセージが生成される場合があります。エクスポート中に生成されたメッセージは、データベース スキーマのエクスポート ウィンドウに表示されます。エクスポート後、これらのメッセージは、警告に関連する SQL ステートメントを含むその他の詳細とともに、schema_export.log ファイルにも書き込まれます。特定のテーブルまたは列に関する警告メッセージも、"/* <message> */" という形式のコメント マークが付いて、schema.sql スクリプトに追加されます。

問題：COLLATE 属性のあるテーブル列がある場合は、スキーマのエクスポート時に次の警告が返されます。

[警告] 1 つ以上のテーブルが照合順序 'UPPER.ALT' を使用しています。インポートする前に、このファイルをインポート データベースの場所にコピーする必要があります。

このようなメッセージの 1 つが、データベース内の一意のコレーティング シーケンスごとに入ります。

処置：すべてのコレーション ファイルが新しいデータベースの場所にあることを必ず確認したうえで、スキーマをインポートします。

問題：スキーマのエクスポート中、無効なサイズや小数位が検出されると、次のようなメッセージが返されます。

[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 ファイルを編集して、その他の重複する列を削除することもできます。このような修正を行わない場合、スキーマのインポートで作成される新しいテーブルは、一意のオフセットに作成された列をすべて含むため、検証エラーが生成されます。

問題：古い DDF のインデックスには、データ ファイルにある Btrieve のヌル キーに対応することを示すフラグが設定されている場合があります。Zen エンジンは、このフラグをレガシー ヌルとして扱うため、使用したり保守したりしなくなりました。スキーマのエクスポートでは、次のようなメッセージが返されます。

[WARN] Btrieve NULL key flag not supported in SQL index <name> on table <name>
（Btrieve のヌル キー フラグはテーブル <名前> の SQL インデックス <名前> では使用できなくなりました）

処置：これは情報メッセージであり、何もする必要はありません。レガシー ヌルと新しい真のヌルの詳細については、『Advanced Operations Guide』の「ヌル値」を参照してください。

インポート中に生成されたメッセージは、データベース スキーマのインポート ウィンドウに表示されます。インポート後、これらのメッセージは、警告に関連する SQL ステートメントを含むその他の詳細とともに、schema_import.log ファイルにも書き込まれます。

このセクションでは、重要なログ エントリの詳細および例、ならびに実行すべきアクションを示します。

問題：schema.sql スクリプトをインポートすると、無効な SQL ステートメントでエラーが返される場合があります。これらのエラーによって、元のデータベースの DDF に指定されたデータベース オブジェクトにあると示された問題には、以下のものがあります。

これらのエラーが発生する原因の一部は、無効なデータ型や列の長さ、相対パスでないデータ ファイルのパスなど、ソース データベース内の無効なエントリによるものです。一方、前のエラーが原因となって引き起こされるエラーもあります。たとえば、CREATE TABLE が失敗すると、後続の CREATE INDEX ステートメントも失敗します。

処置：メッセージとインポート ログ ファイル内の詳細を確認し、エラーの原因を究明します。必要があれば、エラーに関連するすべての SQL ステートメントを schema.sql ファイルで確認してください。たとえば、CREATE PROCEDURE で生成されたエラーはその 1 行目しかログに記録されませんが、schema.sql にはステートメント全体が格納されています。

問題：以下のメッセージは通常、データベースにバリアント レコード定義があることを示します。

[警告] [LNA][Zen][SQL Engine] USING 句内のデータ ファイル '<ファイル名.拡張子>' は既に存在しており、テーブル '<テーブル>' と関連付けられています。

[エラー] [LNA][Zen][SQL Engine]重複インデックスが存在します。

処置：特殊なケース：複数のレコード定義またはバリアントのレコード定義の操作でこれらのメッセージの詳細を確認してください。

問題：以下のメッセージは通常、データベースに参照整合性制約があることを示します。

[エラー] [LNA][Zen][SQL Engine][Data Record Manager] MicroKernel は指定されたファイルを見つけられません（Btrieve エラー 12）。

[LNA][Zen][SQL Engine][Data Record Manager]RI 定義は同期が取れていません（Btrieve エラー 73）。

通常、これらのエラーが発生するのは、［CREATE/ALTER ステートメントに IN DICTIONARY を含める］オプションを選択したために、スキーマのエクスポートにより外部キーの制約が作成されている場合です。ステータス 12 の場合は、データ ファイルが存在していません。ステータス 73 の場合は、データ ファイルが複数の名前を持つデータベースからコピーされています。

処置：参照整合性が設定されたデータベースの場合は、スキーマのエクスポートを［IN DICTIONARY を含める］オプションを選択せずにやり直して、スキーマを再度インポートする必要があります。そうすることにより、スキーマのインポートでデータ ファイルが作成され、そのデータ ファイル内に参照整合性制約の情報が格納されます。

問題：以下のメッセージは通常、あなたが V2 メタデータ データベースからスキーマをエクスポートし、そのエクスポートしたスキーマを v1 メタデータ データベースにインポートしようとしていることを示します。

[LNA][Zen][SQL Engine]テーブル名 longtablenameinv2database が長すぎます。

これらのエラーが発生するのは、ソース データベースで長いメタデータ オブジェクト名、ビューまたはストアド プロシージャ内での 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 ファイルに必要な修正を行って、データベースを再度インポートします。

ZenCC を使用して作成したテーブルは、最初は空です。ZenCC を介して、またはインポートすることによって、これらにデータを追加することができます。ZenCC にはデータをエクスポートおよびインポートするウィザードがあります。

「グリッドにデータ行を追加するには」を参照してください。

「bdu」 を参照してください。

データのインポート ウィザードでは、テキスト ファイルの区切り文字付きデータを読み取って、そのデータをテーブルへ追加します。このウィザードでは以下の項目について選択を行うことができます。

フィールド区切り文字には、カンマ、コロンまたはタブのいずれかを使用する必要があります。レコードを区切る場合は、キャリッジ リターンとライン フィードを併用する必要があります。

データのエクスポート ウィザードでは、テーブルのデータをテキスト ファイルへエクスポートします。キャリッジ リターンとライン フィードを併用してレコードを区切ります。

このウィザードでは以下の項目を指定します。

ZenCC では、ストアド プロシージャ、トリガー、ユーザー定義関数、およびビューを作成する CREATE スクリプトを管理できます。Zen エクスプローラーでは、これらの項目は各データベースのフォルダー内に表示されます。

これらの機能を使用するかどうかは任意ですが、上級のデータベース ユーザーにとっては興味深いかもしれません。

セキュリティは、ユーザーがデータベースにアクセスするためにユーザー名とパスワードを指定することを要求するデータベース プロパティです。デフォルトで、データベース セキュリティは無効になっています。

データベース セキュリティは ZenCC を使用するか SQL ステートメントを実行して無効にすることができます。有効にしたら、グループおよびユーザーを作成して権限を与えることができます。権限は、「データベース」、「テーブル」、「列」の 3 つのレベルでアクセス権を指定できます。

セキュリティの設定を有効または無効にするときは、その時点で、Master ユーザーが接続を 1 つだけ開き、かつ接続している唯一のユーザーでなければなりません。セキュリティを最初に有効に設定した直後には、Master ユーザーのみがデータベースにアクセスできます。Master ユーザー パスワードでは、Zen のすべてのパスワードと同様に大文字と小文字が区別されます。

セキュリティ モードの詳細については、『Advanced Operations Guide』の 「Zen セキュリティ」を参照してください。

このセクションでは、Zen セキュリティのさまざまな管理作業の手順を説明します。次の表では、管理作業をカテゴリ別に示しています。

データベースがリモート マシンにある場合は、管理者のユーザー名とパスワード、またはリモート マシンの Zen_Admin グループのメンバーのユーザー名とパスワードを提供する必要があります。ログインしているローカル マシンにデータベースがある場合（かつ、ローカル マシンでターミナル サービスが実行されていない場合）は、ユーザー名とパスワードは必要ありません。

セキュリティを有効にすると、すべてのユーザーは、データベースの有効なユーザー名とパスワードを使ってログインしない限り、データベースにアクセスできないようになります。セキュリティを有効にするまでユーザー名とパスワードは設定できないため、そのユーザーのユーザー アカウントが設定されるまでの期間、各ユーザーはデータベースにアクセス不能となります。

管理者として、または Zen_Admin オペレーティング システム セキュリティ グループのメンバーとしてコンピューターにログインしている必要があります。

セキュリティを有効にすると、すべてのユーザーは、データベースの有効なユーザー名とパスワードを使ってログインしない限り、データベースにアクセスできないようになります。セキュリティを有効にするまでユーザー名とパスワードは設定できないため、そのユーザーのユーザー アカウントが設定されるまでの期間、各ユーザーはデータベースにアクセス不能となります。

管理者として、または Zen_Admin オペレーティング システム セキュリティ グループのメンバーとしてコンピューターにログインしている必要があります。

これらのセキュリティ ポリシーの詳細については、『Advanced Operations Guide』の 「Zen セキュリティ」を参照してください。

グループを別のグループに追加することはできません。

以下の手順は、ローカルのデータベース セキュリティ モデルを使用する場合にのみ適用されます。Windows ドメイン セキュリティ モデルでは、ネットワーク ドメイン アカウントは Zen データベースへのログインに使用されます。グループ メンバーシップはネットワーク管理者によって割り当てられます。Zen は Windows ネットワーク認証サーバーに照会してユーザーの資格情報を確認し、権限が定義されている Zen グループのメンバーシップを検索して一致させます。

ユーザーは、1 つのグループのみのメンバーになることができます。グループ内のすべてのユーザーは、そのグループに定義された権限と同じ権限を持ちます。ユーザーがグループに参加すると、そのユーザーの個人用のユーザー権限は無視され、所属するグループのアクセス権と PUBLIC アクセス権を組み合わせた権限が適用されます。グループに存在するユーザーに個別に権限を許可したり取り消したりすることはできません。

グループは、ユーザーが割り当てられていない場合のみ削除することができます。

ここで説明するすべての作業に関して、オブジェクトに権限を割り当てるときに、使用する Btrieve ファイルにオーナーネームがある場合は、まず、そのオーナー ネームを GRANT または SET OWNER ステートメントを使用して指定しなければなりません。詳細については、『SQL Engine Reference』を参照してください。

ほとんどのユーザーの一般的なニーズは、インストール中にデフォルトで行われる Zen Enterprise Server、Cloud Server、またはそのクライアントの設定で満たされます。ただし、デバッグ、メモリ使用量、パフォーマンス チューニングなど特定の目的のために、設定を変更しなければならない場合もあります。このような設定は、Zen ではプロパティと呼ばれています。プロパティを管理するには、ZenCC やコマンド ラインを使用します。

エンジンとクライアントのプロパティの参照先については、『Advanced Operations Guide』に記載された以下のトピックをご覧ください。

サーバーとクライアントの設定の詳細については、『Advanced Operations Guide』の以下のトピックを参照してください。

ZenCC では、ファイルを開く場合やファイルを保存（別名保存も含む）する場合に、デフォルトで独自のダイアログを使用します。ZenCC が扱うファイルは SQL ドキュメント ファイルであるため、2 つのダイアログにはそれぞれ［SQL ドキュメントを開く］および［SQL ドキュメントの保存］というタイトルが付けられています。したがって、［ファイル］>［新規作成］を選択すると、SQL ドキュメントが作成されます。

このダイアログを使用すると、システム エンコードとは異なる文字エンコードのファイルを使用する作業が、ファイルを開く/保存用の標準ダイアログで行うよりも簡単になります。たとえば、ワイド文字データを含む SQL スクリプトを作成し、適切なエンコードを指定しないで保存した場合は、データが失われることもあります。この例の場合、使用中のシステム コード ページがワイド文字をサポートしないことが考えられます。

ここでは、以下の項目について説明します。

このダイアログでは、ファイルを開く/保存するときのエンコードを変更することができます。さらに、ファイルを開く（［SQL ドキュメントを開く］）ダイアログでは、選択したファイル エンコードに基づき、データのプレビューを表示します。次の表では選択できるエンコードについて説明します。

ファイルを開く/保存するときにファイルのエンコードを変更できるのに加え、これらの作業時にデフォルトで使用するエンコードを設定することもできます。データのインポート/エクスポート、およびスキーマのエクスポートに対し、このデフォルトのエンコードが共通に使用されます。データ インポート ウィザードを使ったデータのインポート、データ エクスポート ウィザードを使ったデータのエクスポート、およびスキーマの管理を参照してください。たとえば、ファイルを開く場合とファイルを保存する場合で、異なるエンコードをデフォルトとして設定することはできません。

ファイルを開く/保存する前に、それぞれのダイアログではファイル名で使用している文字が有効かどうかを確認します。ファイル名に利用できない文字には、/ : * ? \ " < > | があります。

ファイルを Windows と Linux、または Windows と macOS で使用する場合、これらの文字は Zen でサポートされているどのオペレーティング システムでも使用できません。

［ドキュメント］フィールドには、前回のファイルを開く/保存操作で使用したディレクトリがデフォルトで表示されます。ほかのファイルや場所を選択するには［参照］ボタンを使用します。

SQL ドキュメントを保存する場合は、完全なパスとファイル名が必要です。［参照］ボタンをクリックすると、オペレーティング システムの標準のファイル参照ダイアログが表示されます。

ファイルを開く/保存に、オペレーティング システムの標準ダイアログを使用することもできます。たとえば、システム コード ページ以外のエンコードを使って作業する必要がない場合には、標準のダイアログを利用することもできます。

データのインポート/エクスポート、スキーマのエクスポートで、ワイド文字データを含むファイルを扱えるようになりました。ファイルを開く/保存する場合と同じく、ファイルのインポート/エクスポート時にエンコードを変更することができます。エンコードの選択を参照してください。

このダイアログでファイルのパスと名前を入力するフィールドには、前回データをインポート/エクスポートまたはスキーマをエクスポートしたときに使用した場所がデフォルトで表示されます（データのインポート/エクスポート、スキーマのエクスポートは一貫した設定を利用します）。ファイルをインポート/エクスポートする場合は、絶対パス名が必要です。

［ファイルを開く］ダイアログと［ファイルを保存］ダイアログも参照してください。

BOM 付きのファイルをインポートする場合、BOM はインポート時に認識され、取り除かれます。また、このダイアログ内でどのエンコードを選んでも、ファイルは BOM で指定されているエンコードでインポートされます。つまり、BOM が［エンコード］（オプション）での選択を無効にするということです。

［参照］ボタンをクリックすれば、オペレーティング システムの標準ダイアログを利用することができます。

データ インポート ウィザードを使ったデータのインポートも参照してください。

［データのエクスポート］では、ファイルのエンコードの変更や、デフォルトのエンコード設定が可能になりました。［例：］フィールドには、プレビューでなく、選択したオプションによる例が表示されていることに注意してください。

エクスポート操作では、CHAR データ型と NCHAR データ型の値の末尾の空白が削除されることに注意してください。［参照］ボタンをクリックすることで、オペレーティング システムの標準のファイル参照ダイアログが表示できます。

データ エクスポート ウィザードを使ったデータのエクスポートも参照してください。

テーブル スキーマのエクスポートで、ファイルのエンコードの変更や、デフォルトのエンコードの変更が可能になりました。

データベース スキーマのエクスポート ウィザードにも類似した設定があります。詳細については、スキーマの管理を参照してください。