プライマリーキーに関連した問題

v13からv15にアップグレードすると、次のようなメッセージが表示されて、
そのまま終了します。



検証したのですが、
1.テーブルにはプライマリーキーがすべて設定されている。
2.v13で確認したところ、すべてユニークな値となっている。
3.すべてのテーブルでv13でSEND RECORD、v15でRECEIVE RECORDすると問題はない。
4.v13からv14でも同様のアラートが出る。

プライマリーキーに問題があるとすれば、3は実行出来ないはず、と思うのですが。
このアラートが出る場合は、そもそもプライマリーキーにどんな問題がある場合なのでしょうか。
よろしくお願いいたします。

この件ですが
全テーブルのうち、1テーブルの
み、1レコードのみのUUIDの値が
0000000000000000
になっていることが原因でした。
（テーブルごとに要素数を見て確認しておりましたが、同時にこの値もチェックすべきでした）

当該レコードを削除し、再度試みたところ、バージョンアップは停まる事なく
最後迄参りました。

ただ、現在の仕様では、「当初どのテーブルが問題となり、処理が停止された
か」が、多分4D側では検知していながら、作業者にはそれを把握する事は出来
ません。
対応として、もとのストラクチャ、データをコピーし、後ろからTruncate
Tableを繰り返しては試し、支障なく開くテーブルまで番号を調べてゆく、と
いうことを行いました。
単純に、
0000000000000000
をサーチしてゆけばよかったのですが、そもそも「問題となっている」事が、
UUIDの中に0の値が含まれていることかどうか分からなかったからです。
同様に、お困りになるユーザがいらっしゃるのではないかと思いますので、こ
の作りは見直された方がよいのではと考えております。

「プライマリーキーに関連した問題が検出されました...管理者に連絡してください...これで終了します。」

このメッセージは，デザインモードにアクセスできない状況で表示されます。

プライマリーキー管理ツール（アシスタント）は，デザインモードの一部だからです。

デザインモードにアクセスできるユーザー資格でアプリケーションを開始（インタープリターモード）すれば，プライマリーキー管理ツール（アシスタント）が表示され，どのtableでどんな問題が発生しているのかを知ることができます。



プライマリーキーに関連した問題とは

v14以降，データベースのログが有効にされているのであれば，テーブルのプライマリーキーが必要です。

「プライマリーキーに関連した問題」とは，下記の状況を指します。

A. プライマリーキーが設定されていない
B. NULLが存在する
C. 重複が存在する

このうち，Bだけは条件付きで自動的に是正できます。

A，C，および条件に満たないBは，ストラクチャまたはデータの改変を要する作業となるので，デザインモードにアクセスできない状況では，冒頭に挙げたメッセージが表示されてしまいます。

デザインモードにアクセスできる管理者は，データベースをv14以降に変換する前にAまたはCの条件をクリアするように努める必要があります。一番，確実なのは，変換前のデータファイルには何も手を加えず，空のデータファイルとの組み合わせでストラクチャを変換し，既存テーブルすべてに新規フィールドを追加して，それを自動プライマリーキーに設定するという方法です。そうすれば，必然的に「自動是正できるB」の状態になり，「プライマリーキーに関連した問題」は発生しません。

自動的に是正できるプライマリーキーに関連した問題とは

本来，プライマリーキーのNULLは許されないものですが，データファイル変換（v14以降）直後の1度に限り，フィールドタイプが「自動インクリメント」または「自動UUID」であるプライマリーキーは自動的に新しい値が発行されるようになっています。

v13以前，プライマリーキーの設定は必須ではなかったので，大抵の4Dアプリケーションはプライマリーキーが設定されていないと思います。そのようなデータベースを簡単・手軽に変換するための手段として「変換直後の自動プライマリーキーにおけるNULL是正」という機能が設けられました。

NULLとは

NULLはフィールドの「値」ではなく「状態」の一種です。

フィールドがNULLかどうかは，Is field value nullで判定することができます。

表示についていえば，「自然な」NULLは，"00000000000000000000000000000000"と表示され，SET FIELD VALUE NULLでセットされた「人為的な」NULLは""と表示される点が違います。

一方，""が代入されたUUIDは，"20202020202020202020202020202020"と表示されます。

ですから，データベースにUUIDプライマリーキーが設定された経緯により，上記3種類のNULLが存在し得るということになります。

たとえば，v13で新規データベースを作成し，プライマリーキーフィールドのないテーブルにレコードを追加した後，新規データファイルを作成し，テーブルにプライマリーキー（UUID・インデックス）を追加してから当初のデータファイルを開けば「プライマリーキーはすべてNULL」という状況を作り出すことができます。

このとき，自動UUIDであれば，画面上には，一見，有効と思えるUUID値が表示されますが，ウインドウをリサイズするたびに値が変化することから，実際にはNULLであることがわかります。自動UUIDでなければ，画面上には"00000000000000000000000000000000"と表示されます。いずれにしても，このプライマリーキーはNULLです。

自動UUIDであれば，問題なくデータベースを変換することができますが，自動UUIDでなければ，変換後に「プライマリーキーに関連した問題（プライマリーキーにヌルが登録されています）」が発生します。

参考:

プライマリーキーにNULLが登録（3件）されたv13データベースです。プライマリーキーが自動であれば，無事に変換でき，そうでなければアシスタントが表示される点に注目することができます。

https://drive.google.com/file/d/0B_M-9bo2YDhdVndSQnJKVUd4LXc/view?usp=sharing

「デザインモードにアクセスできるユーザー資格でアプリケーションを開始（インタープリターモード）すれば，プライマリーキー管理ツール（アシスタント）が表示され，どのtableでどんな問題が発生しているのかを知ることができます。」
と思ったのですが、実際は、この画面には推移しませんでした。(パートナープログラムのv15 Professionalです)
v13のストラクチャをV15のアイコンにドラッグして起動する、ということをやっていたのですが、それではプライマリーキー管理ツールは起動しないとのことなのでしょうか。

前の投稿で参照したリンク先のDB（v13）を開き，プライマリーキーの「自動」を外して検証できると思いますが，ストラクチャファイル変換の警告・データファイル変換の警告に続けてメッセージが表示されるはずです。

念のため試しましたが，ドラッグ＆ドロップ操作でも変わりませんでした。

これとは直接関係ないのかも知れませんが、アップグレードの際、開いたストラクチャがライセンスがあるのにWeb公開が出来ない、という現象に見舞われました。
後刻ライセンスフォルダにある旧い（旧バージョンの）ライセンスのファイルをすべて捨てると、正常に立ち上がってきたのですが、ライセンスフォルダの利用状態によって、新バージョンのライセンスの認識に支障があるということはないでしょうか。

v15ではなく，Rリリースで4DBを開いている，ということはないでしょうか。

パートナーライセンスはRリリースも含まれていますが，Rリリースを使用するためには，v15ライセンスを「アップグレード」する必要があります。（パートナー契約期間中に・・・）

ライセンスをアップグレードするには，ライセンス更新の画面で「更新」ボタンをクリックします。

あるいは，デザインモードを使用する（たとえば新規DBを作成する）と更新を促すダイアログが表示されます。いずれにしても，ネットワーク接続が必要です。また，一回の操作でいわゆる「紐付いたライセンス」もまとめてアップグレードされます。なお，アップグレード済みのライセンスはファイル名が「R-」から始まります。

アプリケーションモードは，ライセンスがなくても使用できますから，4DBをドラッグ/ドロップした場合，有効なライセンス無しで4Dを動かしていることに気づかないことがあります。ですから，まず，Rリリースを始めて使用する前に，取り敢えず新規DBを作成すると良いかもしれません。