過去の桐井戸端ＢＢＳ　（桐ver.５）
7055 帳票定義データが多すぎます ちこ 2000/08/04-15:59
ＤＯＳ版の桐Ｖｅｒ．５を最近使い始めました。
初歩的な質問で申し訳ないのですが、どうか教えて下さい。
帳票定義中にレイアウト表示または印刷をしようとすると、
「２４４帳票定義データが多すぎます」（領域を減らしてください。）という
エラーメッセージが出ます。
領域は確かにかなり作っていますが、項目値や文字列の領域を結合して領域を減らしてもエラーは消えず、
計算式として作った領域を減らしていくとある時点でエラーが回避されます。
しかし、どうしてもあと３領域計算式として作りたいのですが、
なにかこのエラーの回避策がほかにありましたら教えて下さい。
よろしくお願いいたします。
7057 Re:帳票定義データが多すぎます 宮城 2000/08/04-16:33
記事番号7055へのコメント
ちこさん、こんにちは。

>エラーの回避策がほかにありましたら教えて下さい。

多すぎるといっているのですから、どうしようもないでしょう。もし、画面伝票でしたら、
１画面あたりのレコード数を減らすというのがもっとも簡単な手です。

画面カードだったら省くかつなげるかですね。

（こいつにひっかかるほどの FRM作って、エラー。気持ちはよ〜くわかります。ご同情申し上げます。）

7058 Re:帳票定義データが多すぎます 佐田　守弘 2000/08/04-16:36
記事番号7055へのコメント
ちこさん
どの様な領域をいくつ作ったかといった事が書かれていないので、何とも言えません
が、おそらくきりの制限によるものかと思います。

佐田守弘(KS-00119)

7060 Re:帳票定義データが多すぎます 佐田　守弘 2000/08/04-16:57
記事番号7057へのコメント
宮城さん
>帳票定義中にレイアウト表示または印刷をしようとすると、
との事なので、どうやら印刷用の帳票の様ですね。

ちこさん
このあたりももう少し詳しくお知らせ下さい。

佐田守弘(KS-00119)
7061 Re:帳票定義データが多すぎます hidetake 2000/08/04-17:56
記事番号7060へのコメント
桐５の設定領域数の仕様は、

設定領域数：ＭＡＸ２５６個／内部領域数：５１２＋α個、だったと思いますが、
帳票で縦方向に１領域として複数行の領域を取った場合、
１領域がｎ行に跨がると内部的にはｎ領域消費するようになっています。

従って、横方向にまとめられるものは横方向でまとめるようにする事で、
ある程度は領域数を稼げる場合があります。

7063 Re:帳票定義データが多すぎます 尾形 2000/08/04-19:51
記事番号7055へのコメント
既にやってあるかもしれませんが、フォーム上で計算せず
表の方で計算して、項目値として印刷してみては？
7064 Re:帳票定義データが多すぎます KH 2000/08/04-20:33
記事番号7061へのコメント
>桐５の設定領域数の仕様は、
>設定領域数：ＭＡＸ２５６個／内部領域数：５１２＋α個、だったと
>思いますが

桐Ｖｅｒ５は確か（？）５１２個の領域を設定できるのではなかったですか？
罫線や集計等の領域を考えても５００個近い領域が設定できると思いましたが。
憶測ですが、計算領域が表のような状態なのかな？
５０行１０列で５００領域になってしまいますね。

7065 Re:帳票定義データが多すぎます hidetake 2000/08/04-20:44
記事番号7064へのコメント
>桐Ｖｅｒ５は確か（？）５１２個の領域を設定できるのではなかった
>ですか？罫線や集計等の領域を考えても５００個近い領域が設定でき
>ると思いましたが。

書いた後で気が付きました。
この原文は、K3 の＊＊さんとのメールで交わした内容で桐４当時のものでした　_o_
しかし、桐５でも、縦方向の領域確保については変更が無かったと思います。
この制限で年間カレンダーが作れずに困っておりました。
結局、桐５でも解決できず...

7066 桐ver.5の領域の制限 佐田　守弘 2000/08/04-23:06
記事番号7064へのコメント
桐ver.5の領域数の制限について確認してもらいました。

桐Ver.5の『リファレンス１』の付録A「桐の仕様」の「帳票」の項目に、
領域 設定可能数: 512／帳票
集計領域数: 100／帳票
と書かれているそうです。

>項目値や文字列の領域を結合して領域を減らしてもエラーは消えず、
>計算式として作った領域を減らしていくと
>ある時点でエラーが回避されます。

と書かれておられましたが、ここで言う計算式とは、一般的な計算式ではなくて、
集計の計算式なのではないかと思われます。
つまり、合計や平均などといった集計計算の領域が多過ぎたために、
この制限によってエラーになったものと思われます。
なお、四則演算や文字列演算、表引きなどといった一般的な計算領域であれば、512領域まで設定できます。

佐田守弘(KS-00119)

内容が具体的に書かれていないので、どの様な事をされようとしているのかが分かりませんが、
集計だけで100領域というのはちょっと想像が付きません。
何らかの回避策がありそうに思うのですが。
7068 Re:帳票定義データが多すぎます Ogo 2000/08/04-23:31
記事番号7064へのコメント

>桐Ｖｅｒ５は確か（？）５１２個の領域を設定できるのではなかった
>ですか？罫線や集計等の領域を考えても５００個近い領域が設定でき
>ると思いましたが。

罫線は領域の数には含まれません。
５１２個制限に引っ掛かって、途方にくれている場合でも、罫線の追加は自由に出来ていましたから。(^^;

7070 Re:桐ver.5の領域の制限 hidetake 2000/08/05-00:01
記事番号7066へのコメント
>桐Ver.5の『リファレンス１』の付録A「桐の仕様」の「帳票」の項目に、
> 領域 設定可能数: 512／帳票
> 集計領域数: 100／帳票
>と書かれているそうです。

しかし、この 512 と言うのがやっかいで単純では無いのですよ！
複数行にまたがる場合や、複数行にまたがっても実際にデータが
何行にわたり印刷されるかで異なって来ますから...

例えば、伝票形式で「１」と言うデータを入れた文字列領域で、
２桁×５０行の領域をいくつ作れるか、また１桁×５０行にしたらどうなるか...

7071 Re:桐ver.5の領域の制限 hidetake 2000/08/05-00:07
記事番号7070へのコメント
あと、画面伝票でも明細行が複数行ある場合は、設定は１領域でも
その複数行分領域数を食いつぶしてしますので注意が必要です。

DOS/V 機対応になり、桐も V-TEXT が望まれても、この制限を無くさないと
実用にはならないと感じたことがあります。　(;_;)

7073 Re:桐ver.5の領域の制限 hidetake 2000/08/05-00:24
記事番号7070へのコメント
>２桁×５０行の領域をいくつ作れるか、また１桁×５０行にした
>らどうなるか...

この２桁と１桁については、またウソを書いたかも知れません。　_o_
でも、桐の仕様上の領域数の制限で、実際に設定できる領域数は
見た目でいくつとか単純に出せる物では無いと言われたことがあります。
あくまでも内部的な領域数だと...

7079 Re:帳票定義データが多すぎます ちこ 2000/08/07-12:02
記事番号7055へのコメント
ちこです。遅くなって申し訳ありません。（職場でしたみれないので。。。）

皆様、沢山のご意見・ご回答本当にありがとうございました。
質問の内容が不十分で申し訳ありません。

帳票印刷の伝票形式で明細部５０行、１明細５０行の帳票です。
データの内容は成績管理で表定義で科目（１２４科目）に対して点数と点数による評価を項目定義しているため、
実際のところ表定義でも項目が多すぎたため（２５５を
超えてしまう）２つの表に分けて、この帳票では結合表を指定しています。
ただ、結合表も２５５という制限があり必要な項目が定義できず、帳票定義で仕方なく計算させようとしたら、
今度は帳票定義でひっかかったという次第です。
（なので、これ以上表定義で計算させる項目も作れません）

領域のデータ形式を調べてみたところ、
文字列：１６３、項目値：１２７、計算式：１４８、計 ４３８でした。

この状態で、もう一つ計算式の領域を追加するとエラーになります。

最初定義していたときに、「これ以上定義できません」というようなエラーが発生したときに、
文字列定義をいくつか結合させて減らして回避しましたが、
今回のエラーは定義やファイル保存はできるのですが、印刷時にエラーが発生して印刷できない状態です。
ただ、最初何を減らしていいかわからず、とりあえず文字列領域を減らそうと
３桁１行の領域が２０行くらいある領域を１桁２０行で１つの領域として
いくつか変更しました。（何の効果もないようでした）

計算式はほとんど#COND関数で点数により評価を表示させています。

そもそも表定義の仕方がまずいでしょうか？
このように項目数が多い場合はみなさん、どうしていらっしゃるのでしょうか。
またご意見がいただけたら幸いです。
よろしくお願いいたします。

7080 Re:帳票定義データが多すぎます 宮城 2000/08/07-16:49
記事番号7079へのコメント
>計算式はほとんど#COND関数で点数により評価を表示させています。

ものすごく重くなっていませんか？　私なら、項目計算式やめて、
CMDに置換コマンドを書きます。

7082 Re:帳票定義データが多すぎます KH 2000/08/07-23:49
記事番号7079へのコメント
>帳票印刷の伝票形式で明細部５０行、１明細５０行の帳票です。
>データの内容は成績管理で表定義で科目（１２４科目）に対して点数と点数による評
>価を項目定義しているため、実際のところ表定義でも項目が多すぎたため（２５５を
>超えてしまう）２つの表に分けて、この帳票では結合表を指定しています。
>ただ、結合表も２５５という制限があり必要な項目が定義できず、帳票定義で
>仕方なく計算させようとしたら、今度は帳票定義でひっかかったという次第です。
>（なので、これ以上表定義で計算させる項目も作れません）
>
>領域のデータ形式を調べてみたところ、
>文字列：１６３、項目値：１２７、計算式：１４８、計 ４３８でした。


　素朴な疑問ですが、科目数が１２４もある成績管理とはどのようなものなのでしょうか。
差し支えなければ教えてください。
５年以上も前になりますが、成績管理ではありませんが、１年から３年までの成績処理を
桐５で作成した事がありますが、単純に考えても、高校あたりでは１年間に多くても
２０科目程度の学習が一般的ですが、それを３年間としてみても６０科目ぐらいだと思われますが。
もちろん、選択教科を多く取り入れているところはこの限りではありませんが。
もしかすると一般的ではない全然違うことが前提にあるのかなと思ったものですから。
水を差すような疑問ですいません。　
7084 桐ver.5 帳票の制限について 佐田　守弘 2000/08/08-01:21
記事番号7079へのコメント
ちこさん

●帳票の制限に関して
桐ver.5の帳票の制限として、領域数が512、内、集計領域が100とお伝えしましたが、
これ以外の原因でエラーが生じる場合もあるそうです。
桐ver.5は、印刷に先立って、帳票の定義内容をメモリに展開します。これは、定義内容を
桐が解釈すると考えればよいでしょう。具体的には、領域に設定されている項目名や計算式、
集計などの内容の他、罫線もメモリに展開されます。
そして、これらの帳票の定義内容の展開には、メインメモリが割り当てられる仕組みになっているそうです。
しかしながらMS-DOS環境ではその使用上の制限から、使用できるメインメモリの容量に制限があります。
このため、帳票の定義内容を展開できるメモリ領域はサイズが決まっています。
桐はページバッファなどにEMSを使用しますが、帳票の定義内容の展開など、頻繁に参照される処理には、
処理速度の関係でメインメモリを使う様になっているとの事です。
このため、帳票の定義内容があまりに複雑な場合、定義は行えても、印刷を実行する段階でそれを展開する
メモリが足りなくなると、エラーが表示されるとの事です。

●内部領域数について
hidetakeさんが内部領域数について言及されておりますが、元来「内部領域」なる概念はないそうです。
ただし、定義内容を展開するために内部のメモリ領域が使われるという事を、この様な言い方で表現しているのであれば、
定義画面での領域数とは別の制限があるといった意味で、或いは同じ事を言っておられるのかとも思います。

●対処方法
はっきり言って困りました。
１升ビンに１升５合の酒を詰めてほしいと言うのと同じ状況です。どうしたら良いものでしょうかね。
表のデータの持ち方や、帳票の設計のしかたなどで何らかの回避策があるかも知れませんが、
実際のデータを拝見していないので、このあたりは何とも言えません。
どうやら学校での成績処理と拝見しますので、この点については、その分野に詳しい方の
御意見やアドバイスをお願いしたいと思います。

また別の回避策として、制限が大幅に緩和されているWindows版桐を使用するのも１つの方法ではないかと思います。

●Windows版桐のレポートの制限について
ヘルプファイルには、レポートのオブジェクト数の制限は1000までと書かれていますが、
現在はその制限はしていないそうです(実メモリと仮想メモリの許す限りで青空天井？)。
ただし遠い将来に様々な環境の変化により、使用できるメモリに制限が生じた場合
(その様な事はあり得るのか？)の布石として、「設定するオブジェクト数は、ページあたり1000個程度にしておいた方が
良いでしょう」程度の意味だそうです。
とは言え、本当にその様な制限をする事態になるのかは、私としては疑問です。
（仮にパソコンのメモリとハードディスクの容量が減少する時代が来れば別でしょうけど。
あるいはOSが極端に肥大化して、ユーザーが使えるメモリ領域が極端に減るとか。）

佐田守弘(KS-00119)
7085 桐ver.5 帳票の制限回避の案 佐田　守弘 2000/08/08-02:15
記事番号7084へのコメント
ちこさん
前発言を書いた後でふと思いついた案です。

桐が印刷前に定義内容をメモリに展開すると書きましたが、この時に、項目名や計算式などは
記述通りの文字列でメモリに書かれると思われます。
つまり、例えば[３学年全生徒成績平均]といった項目名だと10文字分(20バイト)必要ですが、
[３全平]だと３文字(6バイト)で済みます。
つまり、項目名を短くするだけで、展開時に消費するメモリが少なくなる訳です。

同様に計算式についても、式の書き方を工夫して短い文字列で表現できれば、展開時のメモリ消費も
少なくなるのではと期待されます。

思いつきだけで確認をとった訳ではありませんが、宜しければ試してみて下さい。

佐田守弘(KS-00119)
7086 Re:帳票定義データが多すぎます hidetake 2000/08/08-05:56
記事番号7079へのコメント
最終的な手段としては、印刷として普通、"項目タイトル" [項目名] とか
"計算式タイトル" [計算式] のように、タイトル(項目名)と結果をわけて
領域定義すると思いますが、これを１つの計算式として連結して領域定義
する方法もあります。

通常のタイトル(項目名)の領域を無くし、結果１つの計算式領域として、
文字列の項目あるいは計算式の場合は、"タイトル"+[項目名] あるいは
"タイトル"+[計算式] とします。
数値項目の場合は、"タイトル"+#str([項目名]) のようにしますが、表示置や
カンマの取り扱いを考えて、
"タイトル"+#last(#通貨文字列([項目名],""),12)
とする事も可能です。

平均点などで小数点がある場合は、
"タイトル"+#last(#str([項目名],-2),12)
と言うようになります。なお、関数についてはマニュアルを見てください。
(#last=#右側文字列 , #str=#文字列)

この領域数のエラーが発生する場合、通常は計算式の複雑さより、
やはり領域数の不足が原因なので、上記の対策でいけると思いますが、さて...

あと先に書きましたが、縦方向の領域をまとめる事は、領域数の削減には
関係ありませんので、レイアウトも含めて横方向でまとめるようにされた方が良いと思います。

PS.
内部領域数に付いては、私自身が桐の内部仕様を知るはずもなく、
これはK3 提供のどこかの資料から引っ張り出した物と思います。
しかし、これを書いたのも 1992 年の事で、どこから出したか思い出せませんが、
ひょっとしたら、一般公開された桐Ｖ４のβ版の資料かも知れません。


7092 Re:桐ver.5 帳票の制限について hidetake 2000/08/08-22:25
記事番号7084へのコメント
>１升ビンに１升５合の酒を詰めてほしいと言うのと同じ状況です。

ひょっとして、桐４の
設定領域数：ＭＡＸ２５６個／内部領域数：５１２＋α個
が、桐５では
設定領域数：ＭＡＸ５１２個／内部領域数：１０２４＋α個
になったのかな？

桐５で、文字列で「1」とだけ記入した、２桁×５０行の
領域をコピーしていくと、２１個＋２桁×４０行までは
可能だけど、２２個目を２桁×４１行にすると領域数の
不足が出ます。５０×２１＋４０＝１，０９０まではＯＫのようですね！

よほど計算式が複雑な場合の問題も他にあるのかも知れないですけど...


7093 Re:桐ver.5 帳票の制限について hidetake 2000/08/08-22:38
記事番号7092へのコメント
>桐５で、文字列で「1」とだけ記入した、２桁×５０行の
>領域をコピーしていくと、２１個＋２桁×４０行までは
>可能だけど、２２個目を２桁×４１行にすると領域数の
>不足が出ます。５０×２１＋４０＝１，０９０までは
>ＯＫのようですね！

２桁×８０行の領域をコピーしていくと、
１３個＋２桁×５１行までは可能だけど、
１４個目を２桁×５２行にすると領域数の不足が出ます。
８０×１３＋５１＝１，０９１まではＯＫのようですね！

7094 Re:帳票定義データが多すぎます ちこ 2000/08/09-12:30
記事番号7079へのコメント
ちこです。
いろいろなご意見をいただき、本当に勉強になりました。
皆様からのアドバイスにしたがっていろいろとやってみました。

宮城さん
>ものすごく重くなっていませんか？　私なら、項目計算式やめて、
>CMDに置換コマンドを書きます。

桐初心者かつ勉強不足のため置換コマンドなるものがどういうものか
よく分からないのですが、マニュアルで見る限り私のやりたいことは
できないような気がします。
各科目の項目があり、一つずつその科目の点数が入力されているのですが
その点数により「優」、「良」、「可」と表示させるというもので、項目名がそれぞれ違うので使えないようです。
（的はずれのことを言っていたら済みません）

KHさん
>素朴な疑問ですが、科目数が１２４もある成績管理とはどのようなものなので
>しょうか。差し支えなければ教えてください。

実は短大の成績管理をやっていまして、ある学科で２年間に用意されている科目が
選択科目も含めてそのくらいあるんです。しかしよく確認したらコースによって絶対に選択しない科目があることが
判明したため、コースの項目を設けて判定させるようにすれば、
表定義にして４８項目、帳票定義では１００領域近く減らせることができるようです。

佐田さん
>また別の回避策として、制限が大幅に緩和されているWindows版桐を使用するのも
>１つの方法ではないかと思います。

いろいろとご説明いただきありがとうございます。
職場の上司に確認したところWindows版の桐を購入する気はなく、
今成績管理のシステムをAccessに移行させるために作成中なのだそうで、
今年度はこのままやるように指示されてしまいました。とほほ。。。

>印刷前に定義内容をメモリに展開すると書きましたが、この時に、項目名や計算式な
>どは記述通りの文字列でメモリに書かれると思われます。

おっしゃるとおり、表定義で項目名をかなり長く書いていましたので、
極力省略した項目名に変更して定義しなおしてみました。
しかし結果は変りませんでした。「領域を減らせ」というエラーだったので、
無駄に領域を取っていた項目の桁数をかなり減らしてみましたが、やはりダメでした。
項目値の領域はかなり作れるのですが、計算式にすると１つも作成できないんです。
項目値と計算式では消費するメモリがかなり違うのでしょうか？

hidetakeさん
>印刷として普通、"項目タイトル" [項目名] とか"計算式タイトル" [計算式] のように、
>タイトル(項目名)と結果をわけて 領域定義すると思いますが、これを１つの計算式
>として連結して領域定義する方法もあります。

私なりに試してみたのですが、結果は変りませんでした。
やっていて、領域の数というよりはやはり消費するメモリの問題のように感じました。

>縦方向の領域をまとめる事は、領域数の削減には関係ありませんので、
>レイアウトも含めて横方向でまとめるようにされた方が良いと思います。

そうなんですか。。。本当に勉強になります。
早速縦方向のまとめた領域を分割したのですが、途中で「５１２を超える」と怒られてしまい、
ある程度の縦方向の領域は残さざるを得ませんでした。

皆様からいただいたアドバイスを１００％理解して試せた訳ではないと思いますが、
前述のとおり表定義から見直して項目を減らすようにしようと思います。
本当にありがとうございました。

7095 Re:帳票定義データが多すぎます hidetake 2000/08/09-13:44
記事番号7094へのコメント
ちこさん、相当複雑な計算式を持ったフォームのようですね！

内部領域よりも、512 の領域数の方の制限に先にかかるようですし、
項目値の領域は OK で計算式の領域は NG と言うのも、始めて聞きました。

これから先は現物で試してみないとわかりませんが、計算式自体が複雑で長いのが
制限にかかっている場合、それをどう短く、簡単に記述するのか、
あるいはどこで計算させるのかと言う課題があるのだと思います。
もし、計算式の領域数自体が問題になっているのであり、
計算式でも単純な変数が通れば、#progn <#計算>を使い、#setq <＃変数>と組み合わせ、
１つの計算式領域で、そこの領域の答えと変数に別の答えを出し、
別の答えは変数を使い表示させると言う手段もあるのかとは思います。

何れにせよ一筋縄ではいかない問題のようですね...
でも、表定義自体を見直されるのでしたら、それが１番かも知れません。


7103 Re:桐ver.5 帳票の制限について hidetake 2000/08/10-05:53
記事番号7093へのコメント
一部訂正しておきます。

上記の通り、領域を縦方向に取った場合、最大領域数 512 までには
ほど遠い領域数でも内部領域数を食いつぶし、ホンのわずかな領域しか
設定できない場合があります。

しかし、最大領域数 512 の制限が先にくるような状況下で設定している場合で、
しかも内部領域数にまだ空きがある場合は、縦方向への設定で
領域数を少しでも減らし別の領域を確保する事は可能です。

と言うことで、単純に縦方向の領域確保は領域数に取っては無意味だと言うのは間違いでした。
512 の制限と内部領域数の制限の元でバランスを取って領域を確保する必要があると言うことになります。


7106 ありがとうございました。 ちこ 2000/08/10-10:36
記事番号7094へのコメント
ちこです。

最終的には、成績管理の仕様を見直して余分な項目を大幅に削除することができましたので、
表定義を変更して再編成しました。
そして問題の帳票定義も今まで文字列として固定で出していた科目名をフラグ判定により
項目値を表示するように変更し、領域も１００近く減らすことができました。

ＦＤ１枚１学科で表定義と帳票定義を入れて管理しているのですが、毎年科目も増えてきて、
そろそろ限界だったようです。
私は今年からこの管理を任され、おまけに桐も使ったこともないときて、訳もわからないまま
既存の仕様に沿って修正をかけていましたが、やはり成績管理の仕様とシステム全体の把握を
きちんとしてから行わなくてはならないと反省させられました。
そしてもっと桐を勉強すれば、もっと効率のよいシステム作りができるんだろうなぁと思いました。

今回の問題にぶつかって、皆様からいろいろなアドバイスをいただけて本当によかったと思っています。
皆様、本当にありがとうございました。今後ともよろしくお願いいたします。


戻る