過去の桐井戸端ＢＢＳ　（桐ver.８）
12911 レポートにおける#総件数の返り値が単票と一覧表と伝票とでは違う値になる 悲しげ 2001/09/01-18:58
ある表について、単票と一覧表(単独)と伝票(単独)の３種類のrptを作って試しています。
訳あって「#総件数」関数を使って、最終頁での表示を制御しようとしています。
例えば、

#条件選択(#頁番号<#ceil(#総件数/27),"次葉に続きます"\
　　　　　,1,"年間合計額（円）")

のように。
この意味は、明細の繰り返し数が27である伝票において、
頁最下行の表示を、最終頁ならば「年間合計額」とし、
それ以外では「次葉へ続く」としているつもりなのですが、
さて、ドツボとは次のとおりです。

#総件数の返り値が、単票と一覧表と伝票とで違うのです。
例えば、レコード数が40行（削除行無し）の表に対しては、
　◎単票では40（正しい）
　◎一覧表は54（！？）
　◎伝票では68（！？）
どうしてこうなるのか、どこが間違っているのか、
あるいは仕様（？）なのかバグなのか・・・、色々試してみてホトホト疲れたあげく、
問題の所在が#総件数に有りそうなところまでたどり着き、
以てここで質問させていただく次第であります。
よろしくお願い申し上げます。<(_ _)>


ps:
当面の苦肉の対応。
どうせ一括処理（.kev）から使っているので、印刷にかける直前に項目集計を実行して得た「&件数」を、
「#総件数」の代わりに使うことで凌いでいます（こうすると正しく表記されるので）。
12912 Re:rptにおける#総件数の返り値 【多遊】 2001/09/01-20:57
記事番号12911へのコメント
悲しげさん

>レコード数が40行（削除行無し）の表に対しては、
を、作成してみました。　

単票では、テキストオブジェクトで
・#条件選択(#頁番号<#総件数,"次葉に続きます",1,"年間合計額（円）")
・#頁番号
・#総件数

一覧表では、ＰＦに
・#条件選択(#頁番号<#ceil(#総件数/27),"次葉に続きます",1,"年間合計額（円）")
・#頁番号
・#総件数
・#ceil(#総件数/27)

で、表示される数値の確認を行ってみましたが、正常でした。

きっと質問の意味が分かってないのでしょうね。
ちなみに、伝票(単独)は試してません

ところで、
>　◎単票では40（正しい）
>　◎一覧表は54（！？）
>　◎伝票では68（！？）
>どうしてこうなるのか、どこが間違っているのか

この４０・５４・６８は、＃総件数の値でしょうか？


12913 Re:rptにおける#総件数の返り値 悲しげ 2001/09/01-21:54
記事番号12912へのコメント
どもっ、【多遊】さん
さっそくのお試しありがとうございます。

>>　◎単票では40（正しい）
>>　◎一覧表は54（！？）
>>　◎伝票では68（！？）
>>どうしてこうなるのか、どこが間違っているのか
>
>この４０・５４・６８は、＃総件数の値でしょうか？

そうです、そうです、
#総件数の値がrptの種別によって異なると云う。(?_?)

私もまったく別な表を使って伝票rptを作ってみましたら、
そちらは問題ないので（#総件数の返り値）、ますます判らなくなっています。
表の方の問題なのか？
12921 Re:rptにおける#総件数の返り値 アックン 2001/09/03-09:47
記事番号12913へのコメント
こんにゃちゃは。
もう解決しているかもしれませんが。
新しい表にしてみては？

P.S. テストファイルを送りました。

アックン(=^・^=)
12930 Re:rptにおける#総件数の返り値（結論） 悲しげ 2001/09/03-16:22
記事番号12921へのコメント
アックン様のご尽力により、症状を一般的に再現させる方法が見つかりました。

ともかく伝票でも一覧表でもいいのですが、ページフッタを１行設けます。
そのオブジェクト属性を「集計へ」変更しまして、例えば集計種別を「総計」、ソースを#合計([某数値計項目])とします。
するとあら不思議、#総件数の値が、めでたくも悲しくも変わってしまうようです。
あまり意味はありませんが、この時、集計種別を他のもの（例えば「小計」）に変えると、
#総件数の値はまたまた変わってくれます。
いやぁ、よかった、よかった・・・・って、全然よくない。(;_;)
なお、集計オブジェクトまたはページフッタ自体を削除してしまえば、#総件数は正しい値を返すようになることもありますし、
あるいは削除しても直らない場合もあるようです。

＊

そうこうしている内に、本件についてk3サポートから返事を貰えました。

>＃総件数は、そのときのレコード件数を求めるものですが、集計作業を
>行う伝票や一覧表では桐側で擬似的に集計行を作成するためこの行数も
>加算された結果となります。
>したがって、対象表のレコード件数と一致しません。
>対象表ファイルのレコード件数を求めることが目的であれば、この関数
>を使用せず事前に項目集計をすることで値を求めることで対応下さい。

だそうです。
このような設定をされる方が他にいらっしゃるかどうか判りませんが、
今後の参考のために、このログに残しておくことにしましょう。

う〜ん、３日悩んで何だか損した気分。(^^;)

ps:レポート印刷にかける直前に、&件数=#総件数とやった方が項目集計より若干速いでしょうね。
12932 Re:項目集計と#総件数 尾形 2001/09/03-23:08
記事番号12930へのコメント
どうも、悲しげさん。
ツリーとは全然、無関係ですし、多分に重箱のスミモードですが (^^;

>ps:レポート印刷にかける直前に、&件数=#総件数とやった方が項目集計
>より若干速いでしょうね。
これって若干程度の差ですか？

項目集計は、最大値や最小値や平均値を出すため全レコードを見て、計算しているようですが、
#総件数ってどうなんでしょ？

レコード数が多いと、項目集計の時間もバカになりません。
#総件数で待たされる感じは、無いと思ってますが....

12933 Re:項目集計と#総件数 悲しげ 2001/09/03-23:51
記事番号12932へのコメント
どもっ、尾形さん
「若干」かどうかは、ひとえにレコード数によるでしょうね。
この間、私が挙げていた例では数10件程度のデータでしたから、
それくらいなら「若干」でしかないだろう（否、むしろ体感差は無いくらいだろう）との頭がありました。
プラス引き続いての印刷時間のこともあって。
一般論として云えば、#総件数ならばレコード数がかなり多くても瞬時だろうと思います。
私が項目集計を使ったのは、実は、&件数のみならず&合計値や&有効件数も取得したかったからでして、
これだけでは一般的では無いので、他人様には&件数=#総件数の代入を奨めておこうとして追記したのがアレでした。
そのように一般論化しようとした割には「レコード数による差」に言及しなかったことは、
へへ〜っ、ご指摘のとおりでございますだ。(^^;)

さらに余談に流れますが、Winでの項目集計ってDOSのそれに比べて明らかに速くなってますね。
これってエンジンのせいなのか、32bit演算の効果なのか。
ま、いずれにせよ、速いのはよいことです。(^^)

戻る