そこで、ダウンライン レポートを実行します。これにより、ログインしている人のダウンラインにいる全員が集まります。クライアントの一部の人々は、100 レコード未満を返すため、これを問題なく実行します。
ただし、一部のクライアントは 4,000 ～ 6,000 行を返し、約 8 MB の情報を返します。大きなリクエストを処理するには、開発マシンのバッファ制限を実際に上げる必要がありました。
この大量のデータを保存し、複数回連続して実行されるのを防ぐ最善の方法は何ですか?
Cookieに保存できますか？これはサーバー上の多くのメモリを消費するため、セッションは問題外です。
この時点で、私はほとんど何でも受け入れており、古いプロセスをより効率的なプロセスに合理化しようとしています。
現在行われていることは、レコードセット全体をロードすることです。レコードセットをループして、データを return_value セルに構築します。
これは jquery/ajax 呼び出しに変換した方がよいでしょうか?
主な要件は次のとおりです。
クラシック ASP jquery/javascript T-SQL
レポートをページングに変更してみませんか? フェーズ 1: クエリ全体を実行しますが、ページには、選択したページに基づいて適切な行セットのみが表示されます。これで、応答バッファーの問題は修正されました。フェーズ 2: Row_Number() を使用してページングをクエリに移動します。データベースの使用に関する問題は修正されました。フェーズ 3: 「画面に表示」(上記を使用) または「csv にエクスポート」のオプションをユーザーに提供します。csv は適切でコンパクトなので、すべてのデータをエクスポートできる可能性が最も高くなります。
ブライアンの回答records returned / items per pageをさらに進めて、切り上げられるページ数を照会します。次に、クライアント側ですべてのページクエリの結果を結合します。ページは、クエリによって提供されたオフセットから始まります。これで、バッファをオーバーフローさせることなく、クライアントに全額を割り当てることができます。また、インターフェイスとユーザーオプション（ページごとにxを表示）に合わせて調整できます。
質問への回答を考えると、Cookieの使用は賢明ではないように思われます。WebブラウザのCookieのキーの最大サイズはいくつですか。。
ASPを使用してWebサーバー上にファイルを作成し、そのファイルにデータを書き込むことをお勧めします。ユーザーがレポートを要求すると、レポートを再度実行する価値がある「十分な時間」が経過したかどうか、またはキャッシュされたバージョンで十分かどうかを判断できます。ユーザーのログイン詳細は、おそらくファイルまたはSession.SessionIDの命名に使用される可能性があります。あるいは、ユーザーのセッションに新しいものを格納する可能性があります。ログインを使用する利点は、レポートのキャッシュがユーザーのセッションよりも長く存在する可能性があることです。