過去の桐井戸端BBS (桐ver.8) |
11522 | メインサブでフォームの開きが遅い | 尾形 | 2001/06/12-15:22 |
どうも、こんにちは。 以前にも少し話題になってましたけど メインサブフォームは開くのに時間がかかりますよね。 サブフォーム側のグループ項目の仕様だとおもいますが・・・ (あの忌々しい「抽出中」のメッセージです (^^; ) 最近、データが増えてきて、うんざりしてきてました。 で、よく考えたのですが、グループ項目を使わなければいいみたいです。 つまり、メインとサブにリンクを張らず(グループ設定せず)手動でやるようにしました。 サブフォームにボタンを作成して、その中に検索や絞りこみを記述しておいて、 メインのリンク項目のソース値更新イベントあたりで、サブフォームのボタンを実行してやる ような具合です。 もちろん、適切な索引は必要です。 ばっちり解消できました (^_^) 少し面倒ですけど。 サブフォームの数が凄く多い場合は???? もし同じ悩みの方がいたらと思い書きこみしました。 役に立たないかもしれませんが。 もっといい方法等あれば教えてください | |||
11523 | やはり索引が原因ではないかと | 佐田 守弘 | 2001/06/12-19:39 |
記事番号11522へのコメント 尾形さん 具体的な事例で確認している訳でないので断言はできませんが、 グループ化するための索引の問題ではないかと思うのですが。 つまり、索引は作ったはずなのに有効に機能していないという事でしょうね。 考えられる原因としては、次の様なものが考えられそうです。 @索引が実際には不適切であるため グループか項目の順序が違っているなどが原因で、使わせる予定の索引ではグループ化に使えない場合です。 グループ化オブジェクトの設定場所の微妙な位置関係(特に高さ方向)で、 順序が思っている順序と違う扱いになる場合があります。 A共有モードのために索引が無効になる これはどうにも対処方法がありませんね。 でも御提案の方法でも共有モードでは適当な索引が使えないはずかと思います。 もし@の後半に書いた事が原因であったら、グループ化項目を全て選択し、高さと縦方向の位置を合わせてみて下さい。 目に見えない微妙な縦方向の開始位置のずれで、グループ化の順序が、変わります。 もう少し付け加えると、グループ化項目の順序は、グループオブジェクトの出現順ですが、 その出現順とはオブジェクトの左上の点の縦座標が若い方が先になります。 そして同じ縦位置の場合、横座標が若い方が先になります。 佐田守弘(KS-00119) | |||
11525 | Re:メインサブでフォームの開きが遅い | 悲しげ | 2001/06/12-20:37 |
記事番号11522へのコメント どもっ、尾形さん、 確かにメイン&サブで(サブは当然グループ項目でリンク)データが増えると超遅くなりますね。 で、律速段階はサブのグループ選択の過程にある、と。 >つまり、メインとサブにリンクを張らず(グループ設定せず) >手動でやるようにしました。 >サブフォームにボタンを作成して、その中に検索や >絞りこみを記述しておいて、メインのリンク項目の >ソース値更新イベントあたりで、サブフォームのボタン >を実行してやる ような具合です。 >もちろん、適切な索引は必要です。 >ばっちり解消できました (^_^) >少し面倒ですけど。 こうするとメイン&サブフォームの初回表示自体は確かに速くなるでしょうね。 ついでに云えば、場合によってはフォームオープン直後にメイン部とサブ部が 全く関係ないデータが表示されてレレレとなるとすれば、 オープン直後にはサブ部は画面表示をオフにしておいて、 牡丹の押下で(関連データのグループ選択と併せて)画面表示をオンにするってのも一考かもしれません。 ま、それはそうと、ひとつお尋ねさせて下さい。 上記の方法だと、牡丹押下でグループ選択過程に入る訳ですが、その速度はどうでしょう? やはりそれなりの時間を要するでしょうか、あるいは意外と速いでしょうか? つまり、メイン&サブに、オーソドックスなグループ項目的リンクを設定したケースと比べて、 (牡丹押下過程も含めた)トータルな所要時間に、体感的な有意差があるかどうか、 と云う点に興味があります。 もし、おじさんがあれば※、もとひ、お時間があれば、この辺りの実験結果を教えて下さいませ。<(_ _)> ※おじさんギャグを使ってすみません。(^^;) お願いばかりだとナンですから、私が採用している方法も付記しておきます。 私の場合は、サブがふたつあるメイン&サブでして、いずれも正統的(?)に グループ項目でリンクしています。で、データが増えると超遅いです。 古い話ですが、桐v6の頃に試した限りでは、フォームオープンまでに日が暮れると云っても云い過ぎではない (ってことはサスガにありません、やはり云い過ぎですが、ま、雰囲気をお汲み取り下さい) くらいでした。 v7を飛ばしてv8になったら、それでもかなり速くはなったんですが、でも未だ遅い。 と云う訳で、前振りが長くなっていますが(^^;)、 私の場合は、サブ用の表は絞り込んだものを使うことにしました。 サブフォーム対象表は、絞り込みさせることは不可能ではないけれども、 諸般の事情(索引利用の問題等色々)で、別表(絞り込み状態を書き出したもの)を利用するようにしました。 当該メイン&サブフォームをフォーム呼出し(または開く)前に、 サブ用のデータ2本を絞り込み書き出しさせてデータをこしらえておく。 こうすると、律速段階は、主に表の絞り込み書き出し過程と副次的には少なくなったサブのグループ選択過程となって、 トータル的には、まぁまぁの速度を得てはおります。(^^)v が、それでもまだ遅いとは云えるので、尾形さんの実験結果を待って、 乗り換えることも有りですんで、よろしく。 でも、その際も手動で牡丹押下と云うよりは、「フォーム開始」イベントか その次の時点であるところの「タイマー」イベントを私は使いそうだが。 | |||
11526 | Re:メインサブでフォームの開きが遅い | 悲しげ | 2001/06/12-20:50 |
記事番号11525へのコメント 尾形さんに追加質問。 その方式だと、メイン部のレコードが移動した時に、サブ部は自動的に着いて来ないことになりますよね? とすれば、当該牡丹のような処理は、例えばメイン部の「レコード移動」イベントでも実行させる必要があることになるのでしょうか? | |||
11539 | Re:メインサブでフォームの開きが遅い | 尾形 | 2001/06/13-08:53 |
記事番号11525へのコメント こんにちは。 実は、書いた後で後悔しました (^^; 背景をもう少し書きます。 朝から晩までずっ〜と桐で入力しているのですが 途中で止まったりとか、電源をブチッと切ったりするんですね。 後者が多いが・・・ こうなると、最後に閉じた状態に戻りますよね(専有モード時) これが許せないのです。 だからこまめにフォームを再起動させたいのです。 私は明細の登録時にマスタにも加算するようにしているので 明細が抜けるとマスタと不一致なんかにもなりますし。 その為、入力フォームの起動が早ければ(瞬時なら)、 毎回強制的にフォームを再起動させてもいいかなと思っている次第でした。 メインサブフォームに表が張りついていると イベントからその表は閉じる事ができないからです。 こういう問題に対する対策は、フォームを閉じるなんていう 安直な方法でなく、他の方法を探すべきかもしれないですね。 索引や表オープンのモードのミスではないです。 共有で開いてみましたが、延々と待たされました >確かにメイン&サブで(サブは当然グループ項目でリンク)データが増える >と超遅くなりますね。で、律速段階はサブのグループ選択の過程にある、と。 はい。試しに、サブフォームのグループ項目の指定を外してみてください。 起動が早くなると思います >項目的リンクを設定したケースと比べて、(牡丹押下過程も含めた)トータ >ルな所要時間に、体感的な有意差があるかどうか、と云う点に興味がありま やっぱりこれですよね。10万データでの比較です。 メインのリンク項目の変更に対するサブ側の表示はメインサブでは瞬時ですが、 この方法ですと、「ン」と間があきます。 でも、自分的には許せる範囲です (^^; >でも、その際も手動で牡丹押下と云うよりは、「フォーム開始」イベントか >その次の時点であるところの「タイマー」イベントを私は使いそうだが。 もちろんです。 手動と書いたのは、イベントから意図的にリンクを実行させるという意味で書きました。 | |||
11547 | Re:メインサブでフォームの開きが遅い | 悲しげ | 2001/06/13-13:02 |
記事番号11539へのコメント どもっ、尾形さん >実は、書いた後で後悔しました (^^; 今回のコメントを読んで、その気持ちが何となく判ります。(^^;) >途中で止まったりとか、電源をブチッと切ったりするんですね。 >後者が多いが・・・ >こうなると、最後に閉じた状態に戻りますよね(専有モード時) >これが許せないのです。だからこまめにフォームを再起動させたいのです。 >私は明細の登録時にマスタにも加算するようにしているので >明細が抜けるとマスタと不一致なんかにもなりますし。 う〜ん、むしろ、表の破損とかデータ間の不整合発生の問題をどうするか、 あるいは電源断対策とかの方が、m&sオープンの遅さよりも優先しそうな感触ですね。(^^;) 私なら、m&sの設定は正統的なものとして、随時バックアップ(k3等)を取るような方法を採用すると思います。 復旧はバックアップデータから自動実行できるような一括処理も組んで。 「随時」については、試してませんが、「タイマー」イベントなんかが利用できるかもしれない、とか。 まっ、それはそれとして >>項目的リンクを設定したケースと比べて、(牡丹押下過程も含めた)トータ >>ルな所要時間に、体感的な有意差があるかどうか、と云う点に興味がありま >やっぱりこれですよね。10万データでの比較です。 >メインのリンク項目の変更に対するサブ側の表示はメインサブでは瞬時ですが、 >この方法ですと、「ン」と間があきます。でも、自分的には許せる範囲です (^^; 了解です。ワタシ的には多分「許せない」(^^;)と思うので、 今回の尾形方式は心置き無くボツとすることにします。(^^;) |