以前のバージョンからのデータベースの変換

以前のバージョンの4Dで作成されたデータベースは4D v13と互換性があります (ストラクチャーおよびデータファイル)。

• バージョン11や12のデータベースファイルは直接バージョン13用に変換されます。一度変換するとストラクチャーファイルはバージョン12で開けなくなります。他方データファイルについては後述する条件のもと、再びバージョン12で開くことができます。
• バージョン6.x, 2003.x or 2004.xのデータファイルはウィザードを使用して変換され、変換されたファイルは以前のバージョンで開けなくなります。

バージョン11や12のデータベースは、ストラクチャーファイルを4D v13で開く際に直接変換されます。2つのダイアログが連続して表示され、変換されるファイルが以前のバージョンで開けなくなることを警告します。

データファイルが変換される際には、インデックスも再構築されます。

注: 古いバージョンの4D Packを使用しているv11データベースを変換する場合は、変換を実行する前に最新バージョンの4D Pack v11をオリジナルのデータベースにインストールすることをお勧めします。

"Macros.xml"ファイルを使用してメソッドエディター内でマクロコマンドを使用できます(マクロの作成と利用参照)。このファイルはユーザー環境設定フォルダーにあります:

• Windows XP:
  C:\Documents and Settings\UserName\Application Data\4D\Macros v2\
• Windows Vista / Windows 7:
  C:\Users\UserName\AppData\Roaming\4D\Macros v2\
• Macintosh:
  {Disk}:Users:UserName:Library:Preferences:4D:Macros v2:

4D v12では新しいマクロコマンドを使用できます。"Macros.xml"ファイルはカスタマイズ可能なので、新しいバージョンの4Dをインストールしても既存のマクロファイルは自動では置き換えられません。

4D v12の新しいSQLマクロコマンドを使用するには以下のいずれかの作業を行います:

• "Macros v2"フォルダー内の"Macros.xml"ファイルを削除します (過去に編集したことがない場合)。そして4Dを起動すると、新しいファイルが自動で作成されます。
• 新しいマクロを手作業で"Macros v2"フォルダー内の"Macros.xml"ファイルに追加します (マクロファイルをカスタマイズしている場合)。新しいマクロのテンプレートファイルは4Dアプリケーションフォルダーの以下の場所にあります:
  Windows: 4D\Resources\ja.lproj
  Mac OS: 4D:Contents:Resources:ja.lproj

4D v13はv12やv11のコンポーネントを、変換しなくても開くことができます (コンパイルおよびインタープリター)。コンポーネントは常に読み込みのみモードで開かれる点に留意してください。

v13への変換は.4DBファイルのみ可能です。.4DCファイルはアップグレードできません。

v13 に変換された 4D データベースファイルの前方互換性 (前のバージョンで再びファイルを開けるか) について以下の表にまとめます:

(*) v12で明示的に許可していれば、一度v13に変換したデータファイルをv12で開くことが可能です。この設定はデータベース設定のデータベース/データストレージ ページ内、v13 データファイルを開くことを許可設定を使用して行います:

デフォルトではいいえオプションが選択されています。はいを選択すればデータファイルが直接開かれ、都度確認を選択するとデータを開く前に確認ダイアログが表示されます。

このオプションは特定の状況下でデータの復旧を行う目的で用意されており、注意を持って使用する必要があります:

• データを再度開く前: すべてのケースで、v13 インデックスファイル (.4dindx ファイル ) を削除することを推奨します。
• データを再度開いた後: バージョン 13 の新機能がデータベーステーブルに適用されている場合、Maintenance & Security Centerを使用してデータファイルの圧縮および修復を行うことを推奨します。

4Dデータベースエンジンレベルの構造的な変更に伴い、過去のデータベースのストラクチャーおよびデータファイルはウィザードを使用して変換する必要があります。念のため、ウィザードは変換前にオリジナルデータベースのコピーを作成します。

インタープリターストラクチャーファイルを変換できます。ファイルにコンパイルコードが含まれていてもかまいませんが、コンパイルコードは変換時に取り除かれます。変換後に再コンパイルする必要があります。
変換前に4D Toolsユーティリティを使用してデータベースの整合性を検証することをお勧めします (データベースの圧縮、検証、必要に応じて修復) 。変換中に異常を検知すると、処理が停止され、変換ウィザードは4D Toolsを使用するよう促します。元のデータベースのバージョンに対応した4D Toolsを使用してください。

以前のデータベースを変換するには、4Dの開くダイアログボックスでそのデータベースを選択します (ローカルデータベースを開く参照)。変換ウィザードが自動で表示されます: 

データベースを変換ボタンをクリックして、ストラクチャーファイルとデータファイルの標準の変換処理を開始します。詳細 > ボタンをクリックして、変換時に使用されるデフォルトのパラメターを表示したり変更したりできます (以下の段落を参照)。
念のため、変換ウィザードは処理を開始する前に自動でデータベース (ストラクチャーとデータ) の完全なコピーを作成します。変換に失敗しても、元のデータベースを取り戻すことができます。データベースの複製には追加のディスクの空き容量が必要となります。利用可能のディスクの空き容量が足りない場合、警告メッセージが表示され、変換は停止されます。

元のファイルは、同階層に作成されるReplaced Files (Conversion)という名前のフォルダーにコピーされます。データファイルがストラクチャーと同じフォルダー内にある場合、Replaced Files (Conversion)フォルダーには両方のオリジナルファイルが含まれます。データファイルが他のフォルダーや他のボリュームにある場合、Replaced Files (Conversion)はフォルダーごとに作成されます。

注: 変換されるデータベースのカレントログファイルもReplaced Files (Conversion)にコピーされ、新しい空のログファイルが作成されます。

変換時にウィザードが致命的でないエラーを検知した場合、エラーは変換されたストラクチャーと同階層に作成されるDataConversion_Log.logという名前のログファイルに記録されます。

サポートされない古いあるいは廃止されるメカニズムは変換時に取り除かれるか置き換えられます。詳細は4D v11 SQL Upgradeマニュアル (PDF) を参照してください。すべての変更点に関する詳細は4D v11 SQL変換の手引き (PDF) を参照してください。

変換を実行する前に、使用されるパラメターを確認したり変更したりしたい場合は、詳細 > ボタンをクリックします。ダイアログボックスに変換パラメターに関するさまざまな情報が表示されます。対応するエリアをクリックすると、異なる情報を表示するページが開かれます:

• ストラクチャーファイル情報: このページにはオリジナルデータベースのストラクチャーファイルのサイズと場所、および念のために作成されるこのファイルのコピーの場所が表示されます。
• データファイル情報: このページにはオリジナルデータベースのデータファイルのサイズと場所、および念のために作成されるこのファイルのコピーの場所が表示されます。また変換するデータファイルを指定するためにも使用されます。デフォルトでカレントデータファイルが選択されます。阿多ｒしい空のデータファイルを作成するか (新しいデータファイルを作成オプション)、他のデータファイルを選択...ボタンをクリックして他のデータファイルを変換することもできます。
  複数のデータファイルを変換することに関する詳細は、後述の"複数のデータファイルを使用するデータベースを変換する”を参照してください。
  保存先を変更...ボタンを使用して変換後の新しいデータファイルの場所を変更できます。
• セグメント情報: このページにはデータベースに関連付けられたデータファイルのセグメントがリストされます。この点に関する詳細は後述の“複数セグメントのデータベースを変換する”を参照してください。
• ディスク情報: このページにはデータベースが置かれているディスクの空き容量を表示します。
• オプション: このページには変換オプションが表示されます。
  
  • データベースを開く際にコードを実行しない: このオプションが選択されていると、データベース起動時に通常実行されるコードが、変換されたデータベースが最初に起動されるときに限り無効となります。このオプションはOn Startupデータベースメソッドを使用して呼び出されるコードに適用されます。これにより、変換後に発生するかもしれない初期化エラーを回避することができます。

変換後、.4DIndyと.4DIndxインデックスファイルのほかに、4Dデータベースは以下の追加の要素を含みます:

• DataConversion_Log.log: このファイルにはデータベース変換時に発生した異常がすべて記録されます。
• Replaced filesフォルダー: このフォルダーには変換前に、オリジナルデータベースファイル (ストラクチャー、データ、ログファイル) のコピーが置かれます。
• Catalog.xml: このファイルには変換されたデータベースストラクチャーの説明および、4D v12以降で使用される新しい内部的なUUID識別子が書き込まれます (データファイルを変更する参照)。このファイルは同じデータファイルを使用しつつ、ストラクチャーファイルを複数回変換する必要がある場合に使用します。この状況は例えばアプリケーションがバージョン2004で開発されていて、それをv12に変換して使用開始後も、引き続き2004での開発が継続される場合などに発生します。この場合、ストラクチャーファイルのみ変換の必要があります。
  警告: Catalog.xmlファイルを使用した複数回の変換はトリッキーな処理であり、取扱いに失敗するとデータを失うなどの結果を引き起こします。データの保護なしに、エンドユーザーがこの処理を行うことを許可しないようお勧めします。この特別なメカニズムは特定のケースで使用されるものです。v11やv12による運用が始まった後に、バージョン2004で開発を継続することはお勧めできません。

変換したいデータベースが複数の異なるデータファイルを使用している場合、データベースの変換とそれぞれのデータファイルの変換は別々に行います。追加のデータファイルの変換はファイルメニューの開く>データファイルコマンドで行います。

1. データベースをカレントデータファイルとともに変換します。
2. 変換されたストラクチャーが開かれた状態で、ファイルメニューまたは4Dツールバーの"開く"ボタンに割り当てられたメニューから開く>データファイルコマンドを選択します。
   標準のファイルを開くダイアログボックスが表示され、変換するデータファイルを選択することができます。
3. 変換するデータファイルを選択して開くをクリックします。
   変換ウィザードウィンドウが表示されます。選択されたファイルに基づき、データファイルに関する情報が更新されます。変換するデータファイルは、標準の変換の原則に基づき、まず複製され、Replaced Files (Conversion)フォルダーに置かれます。
4. ウィザードウィンドウを受け入れて、変換を起動します。
   変換終了後、変換されたデータファイルはデータベースのカレントデータファイルとなります。

バージョン11よりも古い世代のコンポーネントを含むストラクチャーファイルは変換することができません。ストラクチャーファイルの変換に進む前に、対応するバージョンの4D Insider (バージョン2004まで提供されていたユーティリティ) を使用してすべてのコンポーネントをアンインストールする必要があります。

“新世代”のコンポーネントについては4Dコンポーネントの開発とインストールを参照してください。

4D v12より、データファイルサイズは事実上無制限となりました (OSによる制限を除く)。そのためデータセグメントの作成や利用はできません。

セグメントを含む古いデータベースを変換すると、変換ウィザードはすべてのセグメントを新しい1つのデータファイルにまとめます。新しいデータファイルを格納できるだけのディスクスペースがあるかどうかを確認する必要があります。

データベースのセグメントは変換ｆダイアログの“セグメント情報”ページで見ることができます (前述の“変換パラメターの表示と変更”参照)

変換時にセグメントが失われていると、変換ウィザードはセグメントを指定するよう求めてきます。セグメントを指定することができない場合、変換は実行できません。

データベースをv12に変換する際、テキストデータはUnicodeに変換されます。変換が正しく行われるためには、4Dは元の文字エンコーディングを知る必要があります。デフォルトで、カレントのシステムランゲージに対応するエンコーディングを使用します。
以前のバージョンの4Dでは、キーボードレイアウトプロパティを使用することで、フォームオブジェクトに特定の文字エンコーディングを割り当てることができました。この場合、4Dは元の文字エンコーディングを決定することができません。なぜならプロパティはフォームに格納されていて、データ入力は中間的な変数を通して実行されているからです。

そのため開発者は変換前にこのようなフィールドに対し、明示的に文字エンコーディングを指定しなければなりません。これを行うには変換するデータファイルと同階層にテキストファイルを配置します。このファイルは以下のルールで記述します:

• 名称: multilang.txt
• エンコーディング: ANSIまたはMac Roman (Unicodeは使用できません)
• フォーマット: table_number separator field_number separator subfield_number (オプション) separator dialect_code CRLF
  
  • seperatorは“;”です。
  • 各行は改行 (CR または CRLF) で終了していなければなりません。空行やスペースを使用することができます。

例:
4つのテーブルがあるデータベースで (TABLE_1からTABLE_4).

• TABLE_3には4つの文字フィールドがあります (field_1からfield_4)
• TABLE_4には6つの倍長整数フィールドと、2つの文字フィールドを持つSUBFIELDサブテーブルフィールドがあります。
• “キーボードレイアウト”プロパティは、[TABLE_3 ]field_3と[TABLE_4][SUBFIELD]field_1にギリシャ語を、[TABLE_3 ]field_4 and [TABLE_4][SUBFIELD]field_2にロシア語を入力できるように変更されています。
• この場合、multilang.txtファイルは以下のように記述されます:
  3;3;1049
  3;4;1032
  4;7;1;1049
  4;7;2;1032
  dialect_codeは、Resourcesサブフォルダー内のkeyboardmapping.xmlファイルに記述されています。