- - PR -
DataGRIDのページについて
投稿者 | 投稿内容 | ||||
---|---|---|---|---|---|
|
投稿日時: 2004-08-06 16:17
>FILL() は不要ですよね?DataSetをDataSourceに再設定するだけですよね?
Fillは必要です。たぶんこれが原因ですよ。 (データを作り直す必要がある、と書いた理由ですw) たぶん、なぼなさんはPage_Loadでポストバックでないときだけ、DataSetを作ってませんか? | ||||
|
投稿日時: 2004-08-06 16:18
すいません、さっきの書き込みは忘れてください。
逆にする必要はありません。(僕が寝ぼけてました。) #実際自分も元の順序でやってるし・・・。 #つか、Bindした後に変えても多分反映されないはず・・・。 で、エラーが発生する原因ですが・・・。 DataSet11の中身ってどうなってますか? Sessionとかで、ちゃんと保持されてますか? DataBind()の行でエラーが発生して、そのメッセージが 「CurrentPageIndex 値が無効です。 値は 0 以上で PageCount より小さくなければなりません。」 って事は、DataSet11の内容が前回と変わっている可能性があると思います。 で、予想ですが・・・
となっているという事は多分DataSet11の該当テーブルのレコード件数が0件になってませんか? | ||||
|
投稿日時: 2004-08-06 16:22
(順番の問題であれば)参考に
★初期表示時 With DataGRID .DataSource = 'SQLにて取得したDatset .CurrentPageIndex = 0 .PageSize = 30 .DataBind() End With ★DataGRID_PageIndexChanged時 With DataGRID .CurrentPageIndex = e.NewPageIndex .DataSource = 'SQLにて取得したDatset = ★初期表示時で取得したDataSetと同じ内容 .DataBind() End With で、私のところは問題なしと... [@ちと編集] [ メッセージ編集済み 編集者: えんぞ@見習 編集日時 2004-08-06 16:27 ] | ||||
|
投稿日時: 2004-08-06 16:50
noderaさん、NAL-6295さん、えんぞ@見習さんありがとうございます。
たぶんできました。 この機能があるとかなり便利なので、固執してしまいました。 この考えで動作しております。 ・ データの表示 ボタンイベントで、表示。 1. SQL作成 2.Adapterに設定、Fill() 3.DataGrid.DataSourceにDataSetをセット 4.DataGrid.DataBind() ・ページ表示 ページイベントを拾って 1.データ表示のSQLをAdapterに設定 2.Adapter.Fill() 3.DataGrid.DataSourceにDataSetをセット 4.CurrentPageIndex = e.NewPageIndexを設定 5.DataGrid.DataBind() ということですね? noderaさんの >Web用DataGridはページ切替時でも再度DataSourceに入れるデータを作り直してセットする必>要があります。自分も最初「なに〜〜?」と思った記憶が。。。。 の意味がわかりました。 DataSetがよくないのか、DataGridがよくないのか、いまいち 1回のFILL()が生きないのがなっとくできませんね。 ということは、ページの表示やソートの場合は一回一回FILL()しなければならないのですよね? なんのためにDataSetにキャッシュしてるかわからないのですが・・・ こんなところで理解はOKでしょうか? みなさまありがとうございました。 | ||||
|
投稿日時: 2004-08-06 17:13
このあたり、納得されていないようですが、ASP.NETの仕組みを理解すると納得できるようになると思います。 そのために何かASP.NETの入門書を一冊お読みになられたらいかがでしょうか? また、可能であれば・・・ http://www.atmarkit.co.jp/fdotnet/entwebapp/index/index.html で紹介されている書籍 「.NETエンタープライズWebアプリケーション開発技術大全」 をお読みになられると良いかと思います。 | ||||
|
投稿日時: 2004-08-06 18:29
NAL-6295さんありがとうございます。
なるほど、理由があるわけですね。(あたりまえか・・・) っていうことは、ASP .NETをから入るとわかりやすいとうことですね。 早速、本日帰宅時に本屋に走ろうと思います。 ありがとうございました。 | ||||
|
投稿日時: 2004-08-06 19:49
「ASP.NETのセッション管理の仕組み」
1.基本的にはHTTPを利用したWebシステムなので、通信のセッションは切れる。 2.IISでは、サーバー上にセッション情報を管理して継続性を維持している。(IISの仮想フォルダの設定によるが、15〜20分で廃棄される。つまりセッションが切れる)。 3.IISで設定したアプリケーション(仮想フォルダの設定)毎の管理オブジェクトとしてApplicationがあり、ブラウザからの要求毎にたいする仮想フォルダ単位の接続に関してSessionオブジェクトがある。 4.ブラウザからの(仮想フォルダの設定)要求に対して、他にアクセスしているブラウザがなければApplicationの開始処理が呼び出される。そして、Sessionの開始処理が呼び出される。これらの処理はGlobal.asaxに記述する。 5.Sessionが開始されると、SESSIONIDが作成され、クライアントへの応答時に、たぶんCOOKIEだったと思いましたが(もしかしたらフォーム)、次に接続するときに同じサーバーのセッションにアクセスするためのセッションIDが送られます。 6.次に、クライアントが同じサーバーのアプリケーション(仮想フォルダの設定)にアクセスしたときにセッションIDも渡され(たぶんCOOKIEで暗黙で渡される)、タイムアウトせず該当のセッションがあれば、サーバにある前の情報が引き継がれる。 7.クライアントが違う仮想フォルダ(アプリケーション)にアクセスすれば、セッション切断となり、Global.asaxに定義されたSession終了のメソッドが実行されます。他に同じアプリケーションへのセッションがなければApplication終了のメソッドも実行されます。 「.NETフレームワークによるASP.NET開発」 1.上述のように、サーバークライアントの通信接続は毎回切れます。 そこでHTMLの<FORM>に(つまり、HTTPのPOSTメソッド)_ViewStateという名前の隠し項目(HIDDEN属性)で現在のフォームにあるオブジェクトの全ての状態が設定されてクライアントに渡されています。(画面には見えませんが、ブラウザのソース表示を行うと長い文字列が含まれています。) 2.クライアントでリストボックスやオプションボタン等を変更して送信すると、<FORM>の内容は全てサーバーに送信HTTP-POSTされます。つまり、変更したリストボックスやボタンの変更後の内容と、前の設定状態の_ViewStateの内容がサーバーに送られます。 3.サーバーでは_ViewStateの内容と全ての画面項目(正確にはプロパティでViewStateを有効にしたもの)を比べて、違いがあったものを変更内容として、ボタンクリックやチェンジなどのイベント定義を実行しています。 「ADO.NET」 ・.NETではデータの受け渡しはXMLで行っている。 ・ADO.NETでも、データセットをXMLで定義(スキーマ)し、XMLでデータを受け渡している。 「結論」 1._ViewStateで状態の変更は管理されていますが、表示に関係のないオブジェクト間の関連は保持されていない。そのため、データグリッドへのデータ(DataSet)の設定変更は、イベントに合わせてプログラムで表示範囲を決定するなどを毎回行わなければならない。 2.セッション情報としてサーバのメモリ上にkeywordを付けて保存Session("keyword")できる。ここにはデータセットも保存できるので、前の情報をセッションのタイムアウトまで保存できます。つまり、前の検索結果をそのまま利用することが可能です。 但し、ブラウザが他のページに移らないとセッションタイムアウトまでメモリに残るのでアクセスが多いWebでは注意が必要です。また、更新が多いデータベースでは、保存していたデータセットと情報が変更されている可能性があります。 |