過去の桐井戸端BBS (桐ver.8)
8240 補集合での全行削除 くるみ 井上 2000/10/24-17:05
お世話になります。
単純なことなのですが、重複行をなくして1行にするために、一括処理の中で

絞り込み条件登録 単一化,条件名="単一絞込01",{[種類]}
絞り込み 単一化,条件名="単一絞込01"
絞り込み 補集合
行削除 *

とすればよいとずっとこれまで思っていましたら、うまく行削除 ができていませんでした。
基本的な勘違いかなとも思いますが、どうすればよいのでしょうか、
桐はV8sp6で表は表引きに使っている表で[種類]の1項目だけです。

8241 Re:補集合での全行削除 みすず 2000/10/24-17:35
記事番号8240へのコメント
絞り込み 重複行=2,{[種類]}
を実行してから上記処理を行えばよろしいかと思います。

8242 Re:補集合での全行削除 宮城 2000/10/24-18:41
記事番号8240へのコメント
くるみ 井上さんもっと簡単に

絞り込み 単一化={[種類]}

でいいのですが、くるみ 井上さんの記述で基本的にはいいはずです。

想像してみるに2点。

1.単一化後空だった。ケース制御入れます。

絞り込み条件登録 単一化,条件名="単一絞込01",{[種類]}
絞り込み 単一化,条件名="単一絞込01"
ケース開始
 ケース(.not #終端行)
  絞り込み 補集合
  行削除 *
ケース終了
絞り込み解除

2.まさかとは思いますが、表整理してないので「削除行表示」で表示されることを問題視されているのでは?

どうも違う感じですね。
8243 Re:補集合での全行削除 悲しげ 2000/10/24-19:26
記事番号8242へのコメント
どもっ、くるみさん、宮城さん

単一化後空だったと云うことは有り得ないと思います(^^;)。
ここんとこは「補集合が空」の間違いではないでしょうか?
とすれば、
-----------------------------------------
絞り込み 単一化,条件名="単一絞込01"
絞り込み 補集合
条件(&選択件数>0) 行削除 *
絞り込み解除
表整理 余白割合=・・・・ /*必要あらば*/
-----------------------------------------
とか。
8244 Re:補集合での全行削除 くるみ 井上 2000/10/24-20:10
記事番号8242へのコメント
宮城さん みすずさん ありがとうございました。

宮城さんの「削除行表示」の記述を見て、もしかしてと思い、データの量を見ましたら、表引きに使用していますので
生きているのは400レコードしかないのに、削除行表示をしてみると58000以上のレコードがありました。
一括処理で表引きの表に読込みをさせて整理させていたので、いつのまにやらでっかくなっていたようです。
そこで・・・解除の後に

表整理 余白割合= 10

を一行加えてみました。

うまくいきました。

よくわからないのですが、削除行のレコード数に制限とかがあるのでしょうか?
ありがとうございました。

8245 Re:補集合での全行削除 宮城 2000/10/24-20:33
記事番号8244へのコメント
あらら・・・。(^^;;

>よくわからないのですが、削除行のレコード数に制限とかがあるのでしょうか?

レコード長にもよりますが、いずれ耐え難く重くなっていったはずです。

悲しげさん、お手を煩わせました。m(__)m

8247 削除行を含めた表サイズの上限 佐田 守弘 2000/10/24-23:33
記事番号8244へのコメント
くるみ 井上さん

>よくわからないのですが、削除行のレコード数に制限とかがあるのでしょうか?
>ありがとうございました。

削除行も表データの一部ですから、表のサイズの制限を受けます。
その制限とは、510MB以内である事です。

●削除行とは
削除行は、削除されていてデータ処理の対象から外されているだけで、表に書かれている点で有効なレコードとの違いはありません。

分かりやすい喩えで言うと、不用な書類に「廃棄書類」と書いて元通りの書庫に置いてある状態が削除行の状態です。
そして、書庫に残っている廃棄書類を焼却処分するのが表整理です(書庫の整理と同じ)。

削除行の状態は、本当に廃棄してしまった訳ではないので、もし必要になれば復活する事ができます。
その反面、有効データと同じ様に表に残っているので、それだけ表サイズが増大します。

●レコード数などの制限
レコード数については、仕様には記載されていません。
しかし、レコード番号を長整数で扱う関係上、21億4千7百万行が上限になるはずです。
とは言え、仮に整数型1項目だけの表を作っても、25億6千万行でファイルサイズの上限になりますから、
仕様の様にファイルサイズの510MBだけが上限と考えて良いでしょう。
まあ、重くなる事はありますが、通常の表であれば、100万行位までは作れるのではないでしょうか。

ちなみに私の場合には、郵便番号表の約12万行(索引を入れて約19MB)が今までの最大です。

●表のサイズの歴史
表のファイルサイズの上限は、確か桐ver.4の頃に510MBになって以来、今以て変わっておりません。
それ以前は桐ver.3が128MB程だったかと思います。
そして、桐ver.3当時のHDは、SASIタイプで20〜40MB、最大でも80MB程ではなかったかと思います。
桐ver.4になった頃は250〜500MBの時代だったかと思います。
つまり、この頃まではHDの最大サイズが桐の表サイズの上限とほぼ一致してました。
桐ver.5の頃にはHDは500MB〜1GBではなかったでしょうか。
つまり、この頃になって桐の表サイズの上限まで使えるHDが出回った事になります。

そしてその後Windows時代を迎え、HDの容量は急速に増大します。
今や、HDの容量に比べると、桐の表サイズの上限は圧倒的に小さいサイズになってしまいました。
今後、桐の表サイズの上限が上がる事があるのかどうか。
尤も、そこまでのニーズが果してあるのかどうかが先なのかも知れませんが。

佐田守弘(KS-00119)

8249 Re:削除行を含めた表サイズの上限 くるみ 井上 2000/10/25-00:50
記事番号8247へのコメント
皆様おさわがせして申し訳有りません。

なんとなく遅いなーとは思っていたのですが、最近はPCが早くなったので、
併合処理なども以前は解説書を読みながら、処理が早くなるように書き込んでいましたが、
このところまったく気にしていませんでした。

表のサイズは表整理前で4000KB程度でした。
表整理前の状態で会話処理で単一化・補集合・行削除とやってもうまくいかず、
なんでやと思っていたら基本状態で408レコードなのが並替えると337レコードに減ってしまう現象に気付きました。
並替えるとレコードが減るはずはなく、閉じたり開いたり色々といじっているうちに337レコードに戻っていました。
どの時点で戻ったのかは不明です。

337レコードに戻った表で、表整理せずに一括処理を実行してみるとうまくいきました。
削除行のレコード数が多かったのでこんな現象になったのかよくわかりませんが、表自体に何か異常があったようです。

今後は
行削除の後に必ず表整理を書き込むようにします。

戻る