Tips

データベースの符号が一致しない理由

日付2008/08/08
ID08-019
バージョン11
プラットフォームWin / Mac

UUIDが一致しないストラクチャファイルとデータファイルを組み合わせて開くことはできません。

概要

4D v11 SQLでは、ストラクチャファイルとデータファイルの組み合わせがUniversally Unique Identification(UUID...直訳 : 銀河にひとつだけのユニークな番号)で管理されるようになりました。これは、ファイルの移動やファイル名の変更などにより、誤って違うファイルを起動してしまうことを防ぐ役割があります。UUIDが一致しないストラクチャファイルとデータファイルを組み合わせて開こうとした場合、次のようなダイアログ画面が表示され、アプリケーションを起動することができません。

UUIDについて

汎用一意識別子とも呼ばれ、重複や偶然の一致が起こり得ないとされる一意(ユニーク)の番号のことです。4D v11 SQLでは、メソッド・フォーム・テーブルなど、すべてのオブジェクトにUUIDが振られています。またストラクチャファイルやデータファイルにも、固有のIDとしてUUIDが割り当てられるようになっています。ストラクチャファイルのUUIDは、ファイル新規作成時(またはアップグレード時)に決定します。データファイルのUUIDは、ストラクチャファイルのそれと同じです。

http://ja.wikipedia.org/wiki/汎用一意識別子

UUIDが一致しない理由

前述したように、データファイルのUUIDはストラクチャファイルのそれと同じであり、同一のストラクチャファイルで作成された複数のデータファイルは、自由に交換することができます。UUIDは、アップグレード時に決定されるため、たとえば4D 2004で作成されたストラクチャファイルをアップグレードし、Replaced Files (Conversion)フォルダに移動された旧ストラクチャをもう一度アップグレードした場合、それぞれの新ストラクチャファイルは同一のオリジナルを変換したものであるとはいえ、異なるUUIDを持つ別個のストラクチャとみなされます。そのようなストラクチャのデータファイルは、相互に交換することができません。

WEDDリソースについて

4D 2004以前には、特定のストラクチャファイルと特定のデータファイルを結びつける目的で、'WEDD'と呼ばれるリソースが使用されていました。WEDDは、大文字と小文字を区別する最長255バイトの文字列で、環境設定、あるいはSET DATABASE PARAMETERコマンドで書き換えることができました。WEDDリソースは、ストラクチャファイルやデータファイルのデータフォークに書き込まれる内部リソースです。(4Dのリソースコマンドではアクセスできません。)

WEDDリソースのアクセス例

SET DATABASE PARAMETER(WEDD Signature ;"xxxx")
$error_l:=Get database parameter(WEDD Signature ;$WEDD_t)

WEDDリソースが設定されたストラクチャファイルまたはデータファイルをアップグレードした場合、WEDDリソースも継承され、値は環境設定ダイアログなどで確認することができますが、変更することはできません。4D V11 SQLではUUIDでストラクチャファイルとデータファイルの関係が管理されるようになりました。UUIDが合致することは必然的にWEDDの合致を意味するため、WEDDリソースにアクセスする必要はないはずです。

UUIDが一致しないときの対処方法

前述のように、同じストラクチャを何度もアップグレードした場合、それぞれに異なるUUIDが振られるため、データファイルの交換はできないことになります。データファイルの交換をする方法としては、次のような対策が考えられます。

状況

ストラクチャ base_2004 をアップグレード -> base_v11_a

ストラクチャ base_2004 をアップグレード -> base_v11_b

data_v11_a を base_v11_b で開きたい。

1. アップグレード直後のデータが欲しい場合

アップグレード前のデータファイル data_2004 を base_v11_b で開いて下さい。変換ダイアログが表示され、データファイルが base_v11_b 用に変換されます。(同じUUIDになります。)

2. アップグレード後、更新されたデータが欲しい場合

エクスポート&インポート、SQLなどの方法でデータを移動して下さい。

もちろん、UUIDに関係なく自由にファイルを交換したいのであれば、最初に空のストラクチャをコピーし、すべてのプロジェクトを単一のUUIDで管理するような方法が考えられます。しかしながら、UUIDはプロジェクトの整合性を維持するための大切な情報であり、通常は本来の意図どおりに使用するのがベストです。