ご指摘の問題はVBによる開発だけではなくデータ・ベースをキーなしで作成した当初の設計に問題があります。確かにキーなし物理ファイルに複数のアクセス・パスの論理ファイルをぶら下げることはできますので昔、一時期に物理ファイルをキーなしで作成するように指導した○○がいたようで、根拠のない構成のために後で多くの開発者やユーザーが不便を強いられることになります。キーなし物理ファイルを作成する合理的な利点はありません。それはともかく物理ファイルにぶら下がっている論理ファイルのどれかが物理ファイルのレコードを「一意的」に識別できるキーを持つ論理ファイルが存在しているはずです。これを調べるのは面倒ですが(1) DSPDBR コマンドによって従属論理ファイルを調べる [例] DSPDBR MYLIB/MYFILE [例] DSPDBR MYLIB/MYFILE OUTPUT(*OUTFILE) OUTFILE(QTEMP/DSPDBR)(2) 上記の従属論理ファイルのひとつひとつに対してアクセス・パスを調べる [例] DSPFD MYLIB/MYLF TYPE(*ACCPTH) ----> この中で「固有キー値が必要」(UNIQUE YES) と指定されている 論理ファイルが見つかれば、それが求めるPRIMARY_KEYを持つ 論理ファイルです。 この論理ファイルのアクセス・パスを PRIMARY_KEY として VB を開発してください。
お返事ありがとうございます。ご指摘の通り物理ＦにKEYがないのは古くからの名残のようです。基本設計が２０年以上前の基幹システムなので、クラッシュ＆ビルドが早急に必要で今回のVB.NETでの開発もそれの足がかりなのです。UNIQUEキーは殆どの場合論理ファイルの１番目（FILEL01）に設定されていることが分かっています。しかしVBでFILEL01を指定しても実行段階で「物理ファイルでない」というエラーになってしまいます。よって物理Ｆにキー設定が必要なのだと思っています。Ｉシリーズナビゲータで索引の追加は可能で論理Ｆとして作成されます。しかしPRIMARY_KEYはALTER TABLEで通常追加できると思いますが、実行してもエラーになりますしマニュアルを読んでもADDはありません。なぜかDROPはあります。http://publib.boulder.ibm.com/html/as400/v4r5/ic2962/info/db2/rbafzmstatabl.htmキーの設定に関係なくレコード№は自動的に振られていますが、これをPRIMARY_KEYには出来ないのでしょうか？物理Ｆの再作成しか道はないように思えてきました。
「VBでFILEL01を指定しても実行段階で「物理ファイルでない」というエラー」とありますが、そのエラー・メッセージID 等の詳細はわかりますでしょうか ?確かに SQL や ODBC の場合、物理ファイルと論理ファイルは明確に区別されますがi5/OS では基本的に論理ファイルを更新することが可能ですのでSQL での制約があったとしても 基本的には論理ファイルからの更新もできるはずです。レコード№は DB2/400 では RRN (=レコード番号) というものでレコードの中の項目とは定義されていませんので出力用の項目とすることはできますが、キーとすることはできません。物理ファイルの再作成はリスクをかなり伴います。複数メンバーの場合や物理ファイルのサイズが拡張されていることもあり、また従属論理ファイルがどのような構成されているかを慎重に調べる必要があります。何より関連するプログラムへの影響も考慮しなければなりません。レイアウトやデータに変更がなくても、ファイルが LVLCHK=*YES で再作成されれば、たちまちプログラムからのアクセスは OS によって拒否されてしまいます。
ＱＤＤＳＳＲＣをキー付きに変える。ＣＨＧＰＦをする。うまくいけば、データはそのまま、論理ファイルもそののまま。レベル識別も引き継ぐ。