4D Japan Knowledge Base

同じデータベースを複数回アップグレードする場合の注意点

4D v11 SQLでは、データベースを構成する複数のファイル間の結びつきがこれまでよりも強化されています。特にストラクチャファイルとデータファイルはUUIDで厳密にリンクしています。UUIDは同じ番号が決して存在しないとみなすことができる一意の識別番号です。「万能鍵」のようなストラクチャファイルでデータファイルを開くことはできないので、データベースのセキュリティレベルが向上します。

この仕組みは、以前のバージョンにおけるWEDDリソースとある程度似ています。WEDDリソースは、符号が一致しないデータファイルとストラクチャファイルの組み合わせでデータベースが起動されてしまうことを防いでいました。4D v11 SQLでは、WEDDリソースは完全に不要です。データベースファイルは必然的に符号でリンクされており、4D v11 SQL Release 3 (11.3)からはWEDDリソース用の環境設定も取り除かれました。

以前のバージョンで開発されたデータベースの場合、UUIDはデータベースを変換するときに割り当てられます。後になって変更することはできません。この仕組みを銘記しておくことは肝要です。特にアップグレード後、引き続き以前のバージョンで開発をするような場合にはたいへん重要です。具体的には次のように考えることができます。

バージョン11のストラクチャも、複数のデータファイルを作成し、取り替えることはできます。UUIDが一致しているからです。UUIDはストラクチャを変換したときに定義されることを思い起こして下さい。

ストラクチャとデータを別々に変換することはできます。つまり、ストラクチャを変換し、手を加え、その後エンドユーザに提供すれば、その新しいストラクチャで以前のデータファイルを開こうとするときにデータファイルの変換が発生し、そのとき両者間にリンクが成立します。

データファイルは、どのストラクチャファイルでも開けるわけではありません。「どのストラクチャでも」というのは、同じオリジナルから派生した異なるUUIDを持つストラクチャのことです。同じUUIDを持つストラクチャファイルのコピーなら問題はありません。たとえばバックアップコピーやテスト用のコピーは大丈夫です。大事なのはUUIDが一致することです。

ストラクチャファイルのデータファイルの符号が一致しないために開けなくなる典型的な状況は、同じストラクチャを何度も変換するような場合に生じます。

たとえば、次のようなシナリオが考えられるかもしれません。4D 2004データベースをバージョン11に変換します。つまり、ストラクチャファイルとデータファイルの両方をアップグレードします。少し経ってから、デベロッパは4D 2004ストラクチャに戻り、手を加えてからもう一度v11に変換します。これをUUID Bと呼ぶことにしましょう。これは絶対にしてはいけないやり方です！！！UUID BのストラクチャはUUID Aのデータファイルを開くことができません。事実上、それらがまったく同じデータベースであるということは、この場合、何の意味も持ちません。UUIDが一致しなければ、ファイルは開きません。

こうしたことを避けるための方法はいくつか考えれます。

ひとつめは、アップグレードと同時に、以前のバージョンでの開発を終了することです。4D v11は生産性が圧倒的に高く、強力で便利な機能もたくさん存在します。この場合、変換は一度しか発生しないのでUUIDの問題は起きません。

次に、両方のバージョンで平行して別々に開発を継続する方法が考えれます。この場合、4D v11を使用しつつ、以前のバージョンのサポートを続けることができます。古いほうのデータベースは、再び変換されることがないので、やはりUUIDの問題は起きません。

最後に、catalog.xmlの使用が挙げられます。これは4D v11 SQL Release 3 (11.3)から追加された新しい機能で、同一のストラクチャの複数回にわたる変換を可能にするものです。4D v11に変換したことのあるデータベースをもう一度変換するのであれば、変換前に、そのストラクチャと同じ階層にこのファイルを置いて下さい。そのようにすれば、4D v11.3で変換したとき、新しいストラクチャのUUIDは前回の変換と同じものが使用されます。いずれにしても、catalog.xmlは紛失しないよう注意深く管理することが奨められています。