過去の桐井戸端ＢＢＳ　（桐ver.９）

24647	テキストファイルを読み込むと「KD1511:ファイルサイズが制限を越えています」のエラーが出る	ひろ	2004/02/08-13:02
こんにちは　はじめまして。 桐Ver9-2004をWindowsXP HomeEditionSP1 CPU:Celeron2GHz メモリ256MBで使っています。 表を新規に作成し，項目[A]をひとつだけ作成しました。 この表で，テキスト読み込みを実行したところ，"KD1511:ファイルサイズが制限を越えています"のメッセージを表示します。 入力のテキストファイルは，204MBytあります。読み込みサイズに制限があるのでしょうか？ (テキストの1レコードは約100〜200Bytです) ちなみに，186MBytのテキストファイルは正常に読み込みできました。 なお，HDDの空き容量は91GBytです。 どうぞ宜しくお願いいたします。
24648	Re:ファイルサイズ制限	悲しげ	2004/02/08-16:11
記事番号24647へのコメント 私のは桐V9sp1ですが（V9-2004も大体同じだとすれば） ヘルプの目次／仕様／表に色々上限値が載っていまして 表のファイルサイズは 510MB / 表 となっています。 だから（元のテキストのサイズはさておき）読み込んだ際の表としてのファイルサイズが 多分510MBを超えたのではないでしょうか？ テキストを分割するなりして、複数の表での読み込みを試してみてはいかがでしょう？ なお、その際にファイルサイズのみならず、レコード数やレコード長（１行文字数制限）等の制限もご覧下さい。
24652	ファイルサイズの上限オーバーの原因	佐田　守弘	2004/02/08-17:26
記事番号24647へのコメント ひろさん 表ファイルサイズの上限に関しては悲しげさんが書かれている通りです。 さて、 　>入力のテキストファイルは，204MBytあります。 とありますので、このサイズのテキストファイルを桐の表に読み込むと、 500MBの表サイズ上限を超えるのかどうかについて、多少コメントします。 ●２バイト形式による理由 桐の表では、文字列を全て２バイト形式(JISコード)で記録します。 これは半角英数字の１バイト文字からなる文字列でも同じです。 つまり、元のテキストファイルが英数字など１バイト文字で204MBであったとすると、 表に読み込んだ時に、２倍の408MBになります。 後述の表としての情報が加われば、表の制限を超える事は容易に想像できます。 但し元のデータが日本語文字など２バイト形式であれば、表に読み込んでも データ部分の容量はそれ程変わりません。 ●表形式とするための必要容量 テキストデータは、単に文字データだけの情報ですが、 桐の表は、レコードデータだけではなく、その他に次の様な情報が付け加わります。 ・表の枠組みの情報、・ページチェイン情報、・一覧表印刷などの各種条件名 ・索引データ、・削除行のデータ、表の余白部分、・その他 上記の理由によって、表データの上限を超える原因となる事があります。 そこで、以下の点をチェックしてみて下さい。 �@削除行が残ってないでしょうか。 　テキストを読み込む前に表整理をしましたか？ 　これが最も怪しい様な気がします。 �A索引を設定してありませんか 　読込先の表は１項目だけの様ですが、もしこの項目に索引が付けられていると、 　索引情報として、レコードデータに匹敵する容量を必要とします。 上記の２点が問題ないとしたら、これだけのテキストデータを読み込むと、 それだけの表のファイルサイズになってしまうと諦めるしかないでしょう。 つまり複数の表に分割するしかありません。 でも、もしテキストデータが日本語文章であったとしたら、204KBのテキストを読み込んでも、 500KB以内に収まりそうにも思えるのですが。 あと１つだけ気になるのは、表の余白です。断言はできませんが、 もし読み込み時にページ分割が発生していると、データページの余白が大きくなって、 必要以上に表サイズが大きくなる事があり得ます。 試しにテキストファイルを２つないし３つに分け、１つ読み込んだら表整理を行い、 次のファイルを読み込んでみる方法を試してみて下さい。 表整理の前後でファイルサイズが大きく変わる様なら、この推定は当たっていると思います。 佐田守弘(KS-00119)
24655	表の上限値	佐田　守弘	2004/02/08-18:18
記事番号24652へのコメント 悲しげさんのコメントでは、表のファイルサイズの上限値として510MBと書いてあり、 私のコメントには500MBと書きました。 これについて補足します。 桐ver.5の仕様では510BMと記載されていて、その後のWindows版になった時には、 500MBと書いてありました。 そして現在の桐ver.9-2004では510MBと書いてあります。 以前、この記述は値として異なるものか、同じ値なのかを確認した事がありました。 その答えですが、単に表記の違いだけで、桐ver.5以来ファイルサイズの 上限値の仕様は変わっていないそうです。 （日常的には500MB程度の理解で充分という意味なのでしょうか。） 本当の上限値をバイト単位で表記するといくつになるのでしょうか。 私も調べた事がないので、知りません。 （案外、512×1024×1024バイトが真値だったりして） 佐田守弘(KS-00119)
24656	Re:ファイルサイズの上限オーバーの原因	ひろ	2004/02/08-18:45
記事番号24652へのコメント 悲しげさん，佐田さん，こんにちは。早速のお返事ありがとうございました。 桐のテーブルの上限を超えていたんですね。 今調べましたら,入力のテキストファイルと桐の表に読み込んだファイルサイズは次のようになっていました。 テキスト　桐のテーブル 114MByt −> 298MByt 186MByt −> 487MByt 160MByt −> 418MByt 154MByt −> 403MByt 163MByt −> 429MByt 204MByt −> 512MByt <−エラー テキストを読み込む前に表整理は10%でしており，索引の設定はしていませんでした。 それで，悲しげさん，佐田さんがおっしゃるように，ファイル分割を行い入力ファイルを２つに分けて実行したところ， うまく処理できました。 今後は，エラー回避の為に，上記のファイルサイズで計算すると，２．７倍になるようですので， 逆算して，テキストファイルが188MByt以上ある場合はファイル分割するようにします。 ありがとうございました。
24657	余談＞ファイルサイズ上限値の推定	佐田　守弘	2004/02/08-19:12
記事番号24655へのコメント 前コメントで、ファイルサイズの上限値は500MBないし510MBが公称値である旨を書きましたが、 本当はいくつであるかを推論してみました。 以下は私の勝手な推論です。当たっているかどうかの保証はありません。 桐の表ファイルは、ページ単位で管理されています。破損した表の検査結果として 表示されるメッセージの１つに、「ページチェイン」なるものがありますが、あのページの概念です。 １レコードの最大長さは、4000文字(8000バイト)ですが、これは１ページのサイズから決まる値で、 １ページは8KBつまり8,096バイトでしょう。 （8,000バイトという中途半端な値は取りにくいと思うので） 次に8KBのページを何ページまで持てるかが、おそらく表のファイルサイズの上限になっているのだと思います。 仮にページ番号を整数と同じ2バイト値で持つとすると、2の16乗=65,536が、 ページ数の上限値になるのではないかと思われます。 そこでこれを掛け合わせてみると、 　8,096(バイト/ページ)×65,536(ページ)＝530,579,456 バイト となります。 これを1024の二乗で割ってみると、506(メガバイト)になります。 あくまでも私の推定ですが、この値が表のファイルサイズの上限値の真値ではないか と思われます。 ちなみに、現在の表の最大レコード数は、約40,000,000レコードとなっています。 #行番号関数などで得られる行番号を代入する変数は、長整数ないし数値型が必要な事から考えて、 レコード番号は長整数型で管理されていると思われます。 この値は、カウンタ型の最大値である約40億（4294,967,295）より2桁少ないのですが、 その理由は解りません。 多分、１レコードは100文字以上になるであろうとの前提かも知れませんね。 ●もし表サイズの制限を上げるには 数百GBのHDが存在する現在、510MBの表サイズの制限は少な過ぎないか？ もっと大きくならないものかと思うのですが、考えてみると結構大変な話になりそうな気がします。 ページ番号を表記するのに整数型では間に合いませんから、長整数型が必要になりそうな気がします （３バイト型は多分あり得ないでしょう）。 もちろんレコード数も6万倍になるので、レコード番号を管理するにも長整数型では間に合わなくなって、 4バイト長のデータ型が必要になりそうです。 ページ番号やレコード番号を表すデータのバイト数が増えれば、それだけ処理の負荷が増える事も予想されます。 仮にそこまで仕様を拡大しても、通常使うサイズの表では却って重くなるだけなのかも知れません。 佐田　守弘
24658	参考までに報告して頂けると	佐田　守弘	2004/02/08-19:24
記事番号24656へのコメント ひろさん 結果として、入力ファイルを分割すれば、１つの表に読み込む事ができたと 理解して宜しいでしょうか。 また、以下の事を御報告願えると幸です。 ・読み込んだテキストは、日本語主体であったのか、英数字であったのか。 ・最終的に表整理をしたら、表のファイルサイズはどの程度になったのか。 です。 今後の参考になります。 佐田守弘(KS-00119)
24659	Re:余談＞ファイルサイズ上限値の推定	hidetake	2004/02/08-20:08
記事番号24657へのコメント >●もし表サイズの制限を上げるには >数百GBのHDが存在する現在、510MBの表サイズの制限は少な過ぎないか？もっと大きく >ならないものかと思うのですが、考えてみると結構大変な話になりそうな気がします。 DBPro の主な仕様 http://www.softvision.co.jp/dbpro/catalogue.html#spec ファイル数 無制限（ディスク容量に依存） レコード数 最大約21億／ファイル（ディスク容量に依存） レコード長 可変長：無制限（ディスク容量に依存） 項目数 最大約4,000項目／レコード やはり羨ましいです。
24661	Re:ファイルサイズの上限オーバーの原因	うにん	2004/02/08-23:01
記事番号24656へのコメント >今後は，エラー回避の為に，上記のファイルサイズで計算すると，２．７倍になる >ようですので，逆算して，テキストファイルが188MByt以上ある場合はファイル分割 >するようにします。 使い方によりますが、アンドゥバッファを有効にしている場合、全置換したりすると すぐファイルサイズが2倍ぐらいになりますので要注意です。
24665	Re:ファイルサイズの上限オーバーの原因	アックン(=^・^=)	2004/02/09-08:43
記事番号24656へのコメント ひろさん＞ 表の設定で、ファイルのバックアップをとらないようにしておいてから、 テキストファイルを読み込んでみてはどうでしょうか。 表を編集モードで開いて、メニューの[ファイル]→[ファイル属性]画面で、 「バックアップをとる(R)」のチェックマークをはずします。
24676	Re:参考までに報告して頂けると	ひろ	2004/02/09-22:41
記事番号24658へのコメント 佐田さん，こんばんは。 >ひろさん >結果として、入力ファイルを分割すれば、１つの表に読み込む事ができたと >理解して宜しいでしょうか。 いいえ，入力ファイルを２つに分割し，表も２つにして，それぞれに読み込 みを行い，サイズエラーを回避しました。 >また、以下の事を御報告願えると幸です。 >・読み込んだテキストは、日本語主体であったのか、英数字であったのか。 テキストはすべて英数字です。日本語文字は１つもありません。 >・最終的に表整理をしたら、表のファイルサイズはどの程度になったのか。 >です。 今もう一度実験してみました。以下ファイルサイズです。 １．最初に何もないレコードの状態で，表整理１０％で96KByt ２．テキスト186MBytを読み込んだ直後の表は，487,976KByt 　　（表には 1,611,645レコードあります） ３．表整理１０％で 440,392KByt になりました。 いろいろ，ありがとうございます。
24677	Re:ファイルサイズの上限オーバーの原因	ひろ	2004/02/09-22:45
記事番号24665へのコメント アックンさん　こんばんは。 >ひろさん＞ >表の設定で、ファイルのバックアップをとらないようにしておいてから、テキスト >ファイルを読み込んでみてはどうでしょうか。 >表を編集モードで開いて、メニューの[ファイル]→[ファイル属性]画面で、 >「バックアップをとる(R)」のチェックマークをはずします。 はい。バックアップはとらないようにしていました。 これは，バックアップファイルを作成すると，どうしても時間がかかるため， 処理速度を速めるために，「バックアップをとる(R)」のチェックマークをはずしていました。 ありがとうございます。
24678	Re:ファイルサイズの上限オーバーの原因	ひろ	2004/02/09-22:50
記事番号24661へのコメント うにんさん　こんばんは。 >使い方によりますが、アンドゥバッファを有効にしている場合、全置換したりすると >すぐファイルサイズが2倍ぐらいになりますので要注意です。 すみません，アンドゥバッファを有効にしている場合とは，何でしょうか？ ちなみに，私の場合は，テキストを読み込んだ後，不必要なレコードを削除しています。 全置換とは違いますが,レコードの削除でも同じ事が言えますでしょうか？ 宜しくお願いいたします。
24685	報告内容了解＆バックアップ有無など	佐田　守弘	2004/02/10-01:59
記事番号24676へのコメント ひろさん 報告して頂いた内容につき、納得いたしました。 ●ファイルサイズの件 データが１バイト系の英数字との事なので、桐の表に読み込むと、これだけで単純に２倍になります。 更に、表としての情報の記録の他、読込時に不要な余白が発生するために、 前回書かれていたテキストの2.7倍のサイズになるは、納得できる数字と思います。 読み込んだ後に表整理10%でファイルサイズが小さくなったのは、所々に余白が 大き過ぎる場所が発生したためです。表分割が生じたのかも知れません。 もし、この後追加編集しない表であれば、余白割合0%で表整理すれば、更に 小さくなって、400MB、つまりテキストファイルの2.15倍程度までの大きさになろうかとおもいます。 要するに、ギリギリまで圧縮すれば、0.15倍分が表としての情報量です。 ●バックアップ有り無しとアンドゥの件 他の方々はファイルサイズに影響するのではと書かれていますが、私の考えでは影響しないと思います。 バックアップ有の場合には、編集時にオリジナルファイルに果てを付けずに、 編集用のテンポラリファイルが作られて、編集結果はそこに書き込まれます。 ディスク容量は、バックアップなしに比べて３倍の消費になりますが、 表ファイルサイズには影響しないはずです。 アンドゥ情報もメモリ上(ディスクに作られるキャッシュやワークファイルも含む)に作られるだけで、 表ファイルの中には記録されないはずです。 従って、アンドゥ有り無しも表ファイルのサイズには影響しないはずです。 もちろん、メモリやディスクのワークエリアを消費し、また、アンドゥ情報を残すために 処理速度が下がる事はあります。 佐田守弘(KS-00119)
24692	Re:ファイルサイズの上限オーバーの原因	うにん	2004/02/10-11:33
記事番号24678へのコメント >すみません，アンドゥバッファを有効にしている場合とは，何でしょうか？ 環境設定の「全般」「高度な設定」に「専有モードでアンドゥを無効化し〜」 というのがあります。 >ちなみに，私の場合は，テキストを読み込んだ後，不必要なレコードを削除していま >す。全置換とは違いますが,レコードの削除でも同じ事が言えますでしょうか？ 削除の場合は表整理するまでサイズが小さくなりませんが、元より大きくなることはないと思います。
24702	Re:報告内容了解＆バックアップ有無など	うにん	2004/02/10-14:35
記事番号24685へのコメント >アンドゥ情報もメモリ上(ディスクに作られるキャッシュやワークファイルも含む) >に作られるだけで、表ファイルの中には記録されないはずです。 ワークファイルにも同じファイルサイズの制限があるため、ひっかかります。 （経験済み。） しかも、表ファイルにゴミが保存されるらしく、保存終了すると表ファイルのサイズも大きいままになります。 表整理すると小さくなります。 文字列項目で#文字列反転([])で全置換してみると、データサイズは変わらないはずなのに ファイルサイズが大きくなるのを確認できます。
24704	Re:ファイルサイズの上限オーバーの原因	アックン(=^・^=)	2004/02/10-15:18
記事番号24677へのコメント ひろさん、佐田さん＞ ひろさん、どうも煩わせてしまいました。m(__)m 佐田さん、表のバックアップ有無の違いでサイズが肥大化すると思ったのではなくて、 桐が巨大なバックアップファイルを作る途中で何らかのエラーが生じて、 本来とは異なるエラーメッセージを発したのかなと思ったんです。(^^;
24705	Re:報告内容了解＆バックアップ有無など	hidetake	2004/02/10-15:35
記事番号24702へのコメント >>アンドゥ情報もメモリ上(ディスクに作られるキャッシュやワークファイルも含む) >>に作られるだけで、表ファイルの中には記録されないはずです。 >文字列項目で#文字列反転([])で全置換してみると、データサイズは変わらないはず >なのにファイルサイズが大きくなるのを確認できます。 これって，「専有モードでアンドゥを無効化し〜」の設定以外に 専有状態で置換するか，共有状態で置換するかでも，ふくれあがる ファイルサイズが異なるのですね！　初めて知りました。
24726	Re:余談＞ファイルサイズ上限値の推定	おたけ	2004/02/10-23:01
記事番号24657へのコメント >#行番号関数などで得られる行番号を代入する変数は、長整数ないし数値型が必要 >な事から考えて、レコード番号は長整数型で管理されていると思われます。 >この値は、カウンタ型の最大値である約40億（4294,967,295）より2桁少ないのですが、 この長整数型の最大値はHelpを読むと21億少しで終りのようですが、レコード数約 40,000,000レコード / 表　こうなっているので、以下の一括では長整数型の最大値で ループさせると終りがこない一括になりますね？ Noと言う長整数型項目を一つ定義してます。 /*以下が一括でス*/ 変数宣言　固有,長整数{&i} 表　"test2.tbl" 表表示　[No] 繰り返し　&i=1, 2147483646 行挿入　[No]=&i 繰り返し終了 ---------------------大まちがいだったりして^_^; 同じソースを桐V9とDBProV4.5で同時に実行すると桐のほうが6倍以上早くカウントしてい きます？？？？？＞やっぱり間違いを書いちゃった
24731	肥大化現象のテスト結果	佐田　守弘	2004/02/10-23:21
記事番号24702へのコメント うにんさん、hidetakeさん 試してみたところ、やはりお二人の言われている通りで、様々な条件で、 置換後のファイルサイズがかなり変わる事を確認しました。 【テストに使用した表】 試してみたのは、BBSのログの様なものを読み込んだ表で、ほぼ全体が日本語文字です。 行った置換は、１レコードの大部分を占めている項目に対する文字列反転です。 ●余白割合の影響（専有・バックアップあり、アンドゥあり） 最初に余白割合を変えて表整理を行い、続いて文字列反転の置換を行ってみました。 　余白割合　　0% 3,448,832 　余白割合　10％ 3,907,584 → 7,315,456 　余白割合　30％ 5,087,232 → 8,527,872 　余白割合　50％ 6,529,024 → 9,969,664 余白割合が少ないから、表分割で肥大化するのではないかと考え、余白割合を増やしてみたのですが、 その効果は全く見られず、余白割合が大きい程、置換後のファイルサイズも大きくなっています。 ●アンドゥなしにした場合（専有・バックアップあり） 次に、専有バックアップありの状態で余白割合10%で表整理後に置換を行ってみました。 　置換前：3,907,584 → 置換後：3,907,584 これを見て分かる通り、アンドゥなしにすると、肥大化は生じていません。 肥大化の現象として、単にページ分割が起きているだけと思っていたのですが、 アンドゥ情報、つまり置換前のデータを表の中に残すために、ファイルサイズが大きくなっている様ですね。 但し、削除行をとしては表示されません。削除行ではないけど、削除行の様に表の中に残されていると考えると理解できます。 ●共有モードは極度に肥大化する 次に、同じ表を余白割合10%で表整理した後、アンドゥ有り無しについて共有モードで開いて置換を行った結果です。 　アンドゥありの場合　11,149,312 　アンドゥなしの場合　11,149,312 共有モードでは、アンドゥあり、なしに拘わらず３倍程度に肥大化しました。 この理由は解りません。 以上の通りで、専有モードの場合には、置換を行った場合、置換前の情報を表に残すために肥大化が生じる様です。 そして、表整理を行えば、それらの情報が捨てさられて、表は元の大きさに戻ります。 このテストではありませんが、併合処理の後にアンドゥを行ってみた所、 一見併合前の状態に戻りましたが、併合で挿入された行は削除行で残っておりました。 佐田守弘(KS-00119)

戻る