とりあえず，仕掛りとなっている recnとrefnumの切り分けというのが最大の課題だが，その前にいくつかペンディングを片付けておこう．
▲再現手順5でUndo→Undoしたとき，RestoreNumlistを実行すると，大量の「カード参照番号の重複」エラーが発生する．⇒この関数ではCardNumListとMargNumListに保全された参照番号をリンクテーブルに書き戻している．⇒手順5で最初に基準ソート→ Undoではエラーは発生しない．その後，一括削除→ 基準ソート→ Undo→ Undoで発生する．つまり，障害は基準ソートをUndoした時点ではなく，一括削除のUndoの時点で発生している．これは，一括削除時にNumListがバックアップされていないことを意味するのではないだろうか？
確かに，CardNumListとMargNumListをバックアップしているのは，基準ソートの場合だけだ．基準ソートをUndoした時点ではエラーは発生しない．Numlistが復元されているためだ．ただし，このリストは削除後のものであるため，短いものになっているので，テーブル上で更新されていない部分との間に矛盾が生じている．カード削除の場合などでもつねにバックアップを取るようにしておけばよいのかもしれないが（部分図リストなどはそうしている），時間コスト的にはかなり不利だ．
一番合理的なのは，参照番号をユーザから見えないようにしてしまうことではないだろうか？一覧画面の第一列にはつねに１から始まる通し番号を振っておけばよい．実用的にはこれで何ら差し支えないような気がする… つまり，参照番号はある種の「パーマネントコード」のようなものになる．コラッツ特注版では「氏名」を数値として解釈し，それに準ずるハッシュ値を生成しているが，将来的には「名前」でハッシングすることになると思う．さらに，データベース化ということまで考えると，やはり，参照番号の永久コード化というのは必須なのではないか？
もし，そうであるとすれば，RestoreNumlistという処理は完全に廃絶されることになるのではないだろうか？基準ソートという操作自体が廃絶されるとすれば，Renumberという機能も無用なものになると考えられる．⇒方向としてはこれが正しいのではないかと思われるのだが… その方向に一歩踏み出すことにしよう．Numlistを復元しないとすれば，保全する必要もなくなると考えられる．「参照番号を永久コード化する＠20230109」で止めてみよう．
参照番号の隠蔽というのはよいとは思うが，「カード番号」というのは便宜上いずれにしても必要だ．一覧画面の通し番号でもよいが，一覧画面では一部カードのみを表示する場合があり，その番頭を採用するとなると，今度はカード画面との不整合が発生するようになる可能性がある．これを整合的に操作するのは意外に難しいと思う．むしろ割り切って，参照番号というのはマイナンバーカードのようなものとして公開してしまうという方が整合性が取り易いかもしれない．というか，それしかないような気もする．つまり，「参照番号のマイナンバー化」だ．
これが修正をミニマイズするもっとも賢明なやり方ではないか？これで昨日のチェックするとの項目１～３が片付いたので，いよいよリスト項目７のrecnとrefnumの切り分けに掛かることにしよう．これは前回途中までやって挫折したところだ．一度バックアップを取ってから始めよう．⇒ログを遡って読み直しておく必要がある．⇒この取り組みは2022-12-30頃から始まったものだ．要点をピックアップしておこう．
- 結婚リンクと親番号の不一致→ 暫定的に停止しないように措置した
- 人名テーブルと結婚テーブルについては，IsReferenceを使わない ⇒ この修正は撤回されたものと思われる
- maxrecnumをrecordcountにリネーム→有効レコードカウント
- recordcountは lookup テーブルの count に等しい
- maxrecordを新設し，最大（リンク）レコード番号を格納する
- recordcountの更新時に，maxrecordも更新する．
- maxrecordは単調に増加するものとし，（基準ソート時以外では）テーブルは縮小されない
- getmaxrecnではmaxrecordを返す
- maxrecordのアクセス関数をmaxRecordとする
- getmaxrecnを廃止して，maxRecordに統一する ⇒ getmaxrecnを廃止＠20221226⇒_maxrecnにリネーム
- _maxrecnをリネームしてrecordCountとする
- CHECKREMAINSANSYOを一時停止 ⇒ 現在は有効
- longtableのaddを使う＠20221226 ⇒ FIX
- setmaxrefnumでレコード番号を禁止＠20221227 ⇒ FIX
- 並び替えではリンクテーブルは操作しない＠20221228
- 構造的にオブジェクトの一部として完全に一体化している下位オブジェクトは，スロット接続ではなく，アンカー接続とするのが適当なのではないか？特に，参照リストは通常の参照管理とは別扱いとしなくてはならないのだから，その方が適切であるような気がする．
- ＠20221229で「枝番号と親番号が一致しない場合を許容する」という仕様変更 ⇒ この修正は破棄されたのではないか？
- ①UNDO処理，②参照管理のいずれか，ないし両方が未サポートの場合でも正しく動作しなくてはならない
- CheckMargLinkは静的情報とリンクの整合性をチェックしているので，CARDLINKのHUBOSからの参照が解除されているため，不一致が起きるのはやむを得ない ⇒ フラグを見て除外する⇒対処済み
まず，メンバー変数のリネームから始めよう．
- maxrecnumをrecordcountにリネーム→これはリンクテーブル上の有効レコードカウントを意味する．recordcountはlookup.countと一致しなくてはならない．recordcountはBASETABLE::cleartableで初期化され，incmaxrecnとdecmaxrecnで操作される．
- maxrecnをリネームしてrecordCountとする．
- maxrecordを新設し，最大リンクレコード番号を格納する．テーブルは穴空きの疎な状態で管理されるので，上限を押さえておく必要がある．
- recordcountの更新時に，maxrecordも更新する．
- maxrecordは単調に増加するものとし，（基準ソート時以外では）テーブルは縮小されない．
- getmaxrecnではmaxrecordを返す．
- maxrecordのアクセス関数をmaxRecordとする．
- getmaxrecnを廃止して，maxRecordに統一する
▲MakingLookUpでlookup->countをrecordcount に代入していたところを，一致しない場合には停止するようにしたところ，停止した．recordcount の 237に対し，lookup->countは307で70点の差がある．これはrecordcountのカウントに誤りがあるためと考えられる．⇒UndoProcess→ MakingLookUpでは不一致は避けられないのではないか？⇒一括削除のUndoなので，数字が一致しないのは当然のように思われる．recordcount はBASETABLEのメンバー変数だが，テーブルは基準ソート以外では保全されず，つねにMakingLookUpで再構築するようになっている．とりあえずは，現行論理を踏襲するしかない．
ここで二つのことが考えられる．①基準ソートではリンクテーブルは不変であるとすれば，リンクテーブルを保全する必要はないのではないか？カードの生成・削除はそれぞれのオブジェクトの操作で復元できるはずであり，リンクテーブルはUNDOから切り離すことが可能なのではないか？②UNDOがきちんと動作することが保証されるのであれば，PDB，MDBを保全する代わりにそれぞれのlookupを保全することが考えられる．リンクテーブルはテーブルの最大サイズ分のデータを保持しなくてはならないが，lookupなら有効データが前詰めされているので，かなり有利なのではないだろうか？
もし，これができればMakingLookUpでlookupを再構築する必要がなくなると考えられるのだが…⇒NAMESORTというオブジェクトがあり，CardNumlistとMargNumlistを管理しているが，これらは実質的にlookupと同内容なのではないだろうか？つまり，データとして重複しているのではないか？NAMESORTというのはFAMILYTREEの保持するオブジェクトだ．⇒とりあえず，UNDOでリンクテーブルを保全しない＠20230109としてみたが，問題なさそうだ．