WebSurfer's Home

トップ > Blog 1   |   ログイン
APMLフィルター

Response.Redirect("url", false)

by WebSurfer 2010年9月17日 09:44

以下のようにした場合、Next.aspx に遷移するのは、Response.Redirect メソッドが実行された時点でしょうか、それとも、「時間のかかる処理」が終わった後でしょうか?

protected void Button1_Click(object sender, EventArgs e)
{
  Response.Redirect("Next.aspx", false);
  // ・・・・・・・・
  // 時間のかかる処理
  // ・・・・・・・・
}

MSDN フォーラムで上記の質問があって、その時は前者だと勘違いしていたんですが、正しくは後者(正確には、それよりさらに後のリダイレクト後)でした。

Response.Redirect は、ブラウザに対して HTTP Response Code 302 と遷移先 (Location) の url を返します。それを受け取ったブラウザが指定された url を GET しに行くという仕組みになっています。

(詳しくは、.NET エンタープライズ Web アプリケーション 開発技術大全の ポストバック処理 の図 10 を見てください。)

従って、Web サーバーからコード 302 と遷移先 url 情報を含んだレスポンスが帰ってこないと、ブラウザは Next.aspx に遷移できないということになります。

Response.Redirect メソッドの第2引数を false にすると、上記コードの「時間のかかる処理」が全部終わらないことにはサーバーからレスポンスは返ってきません。

という訳で、上記の質問の答えは後者(「時間のかかる処理」が終わった後)になります。

処理にかかる時間が長いと、その間フリーズしたようになってしまい、ユーザビリティの面でうまくないですね。でも、自分が調べた限りですが、まずレスポンスを返して、その後処理を継続して完了させる方法はなさそうです。AJAX を利用してプログレスをユーザーに知らせることで対応するぐらいしか手はなさそうです。

以下は余談ですが・・・

Response.Redirect("url") または Response.Redirect("url", true) とした場合は、処理をその時点で中断して、即、ブラウザに HTTP Response Code 302 と遷移先 (Location) の url を返します。ただし、中断することによって ThreadAbortException が発生します。

Response.End、Response.Redirect、または Server.Transfer メソッドを使用した場合のそれは仕様だそうです。詳しくは、Microsoft Support の 文書番号: 312629 を見てください。

その文書に回避策も書いてあって、Response.Redirect の場合は第 2 引数を false にすることだそうです。でも、自分は回避策は取っていません。例外がスローされても、どうせ終了するスレッドなので何も問題はないと勝手に判断しています。本当にそれでいいのかという一抹の不安はありますが・・・(汗)

----- 2013/3/21 追記 -----

最近知ったのですが、.NET 4 以降の MSDN ライブラリの説明で、End メソッドの使用は非推奨になっています。理由は、End メソッドでスローされる ThreadAbortException がパフォーマンスに悪影響を及ぼすからだそうです。

HttpResponse.Redirect メソッド (String) は End を呼び出します。従って、このメソッドの代わりに、HttpResponse.Redirect(String, Boolean) オーバーロードを使用し、その Boolean の引数に false を渡し、CompleteRequest() メソッドを呼び出すことが推奨されています。

詳細は、MSDN ライブラリの HttpResponse.Redirect メソッド (String, Boolean) を参照してください。

Tags:

ASP.NET

SQL Server Management Studio

by WebSurfer 2010年9月16日 16:07
SQL Server 2008 Management Studio Express

今回は、Visual Studio の Express 版を使ってのアプリ開発には SQL Server Management Studio(以下 Management Studio)は不要という話です。

というより、下手に使うと予期しない問題の解決にハマってしまい、無駄な時間を費やすことになりかねないので、手を出さないほうがいいですというお勧めです。(笑)

何故 Management Studio が不要かといえば、Visual Studio の Express 版は既定のインスタンスへの接続をサポートしていないからです。

Management Studio で、ウィザードを使ってデフォルト設定のままデータベースを作成すると、Instid\MSSQL\data フォルダに DB(mdf ファイル)が作成され、アタッチ済みの状態になるはずです。

即ち、DB を利用するためには、既定のインスタンスへの接続が必要となります。アタッチされた DB に対して、ユーザーインスタンスを利用した接続はできません。

その DB に、Visual Studio の Express 版を接続しようとすると、既定のインスタンスへの接続はサポートされておらず、ユーザーインスタンスは使えないわけですから、うまくいきません。それに気がつかないと、解決できないことにハマってしまい、無駄な時間を費やすことになるというわけです。

Visual Studio Professional 版は既定のインスタンスに接続できるので、不要とは言い切れません。でも、あまり使う機会はないような気がします。実際、自分は使っていません。

アプリ開発に必要な Management Studio の機能のほとんどが Visual Studio(Express 版を含む) に実装されています。ソリューションエクスプローラを使って SQL Server DB を新規作成できます。データベースエクスプローラを操作して、テーブルやストアドプロシージャの作成も可能です。

という訳で、経験浅い自分の場合ではありますが、今まで Management Studio がなくてアプリ開発に困った記憶はないです。

ただし、アプリ開発時ではなくて、実際の運用で既定のインスタンスへの接続が主になる場合は話は別です。

以前、自サーバーを構築した際の経験では、DB 生成クエリの実行、アタッチ/デタッチ、ログインアカウントの設定、ユーザーの権限の設定等に Management Studio は必須のツールでした。GUI で直感的に操作できるので、コマンドを覚える気のない自分には特にそうです。

Tags:

SQL Server

Visual Studio の接続

by WebSurfer 2010年9月15日 22:13

ASP.NET ベースの Web アプリケーションの開発時に Visual Studio を SQL Server に接続する話です。

(2014/6/11 追記:以下は Visual Studio 2010 までの話です。ユーザーインスタンスが非推奨になり、開発用には、ユーザーインスタンスに代えて、SQL Server 2012/2014 Express LocalDB の使用が推奨されています。Visual Studio 2012 以降ではユーザーインスタンスではなく LocalDB に接続することになりますので注意してください)

Visual Studio のサーバーエクスプローラ(VWD Express 版はデータベースエクスプローラ)を開いてデータ接続のノードを右クリックし、「接続の追加」メニューを表示します。その中の「データソース(S):」の「変更」ボタンをクリックすると、下のような選択画面が表示されます。

Visual Studio からデータソースの選択

SQL Server を DB に利用する場合、選択は以下のとおりとなります。なお、VWD Express, VC# Express, VB Express では既定のインスタンスへの接続ができない(上の画像で「Microsoft SQL Server」のメニューがない)こと、SQL Server Express Edition 以外にはユーザーインスタンスの機能がないことに注意してください。

  1. App_Data フォルダに置いた DB のユーザーインスタンスに接続 ==> 「Microsoft SQL Server データベースファイル」を選択。
  2. ローカルまたはリモート SQL Server DB の既定のインスタンス(または名前つきインスタンス)に接続 ==> 「Microsoft SQL Server」を選択。

自分の場合、開発環境ではほぼ 100% 前者を利用しています。アタッチとかログインなどの設定をしなくても、Access と同様に簡単に SQL Server に接続して DB を扱えるようになりますので。

後者は、SQL Server の知識をある程度得てから、必要があれば利用する程度にした方がよさそうです。Visual Studio のウィザードを使うと、DB の作成からアクセスの設定まで簡単にできてしまいますが、中で何が起こっているか理解していないままやると、後で収拾がつかなくなる恐れがありますので。← 経験談(笑)

SQL Server Express Edition の場合、自動生成される接続文字列は以下のようになります。ご覧のとおり、前者はユーザーインスタンスが有効になっています。(注:SQL Server の Express 版をデフォルト設定でインストールすると「名前つきインスタンス」になります。以下の接続文字列で SQLEXPRESS は名前つきインスタンスの名前です)

Microsoft SQL Server データベース ファイル
---------------------------------------
Data Source=.\SQLEXPRESS;
AttachDbFilename=|DataDirectory|\<mdf ファイル名>;
Integrated Security=True;
Connect Timeout=30;
User Instance=True

Microsoft SQL Server
--------------------
Data Source=.\SQLEXPRESS;
Initial Catalog=<データベース名>;
Integrated Security=True

なお、ここに書いたことは、Visual Studio から DB への接続の話であり、アプリケーションから DB への接続とは違うことに注意してください。

アプリケーションから SQL Server の既定のインスタンスへの接続は、接続文字列の変更と SQL Server 側の設定でどのようにでもできます。

Tags:

SQL Server

About this blog

2010年5月にこのブログを立ち上げました。主に ASP.NET Web アプリ関係の記事です。

Calendar

<<  2024年4月  >>
31123456
78910111213
14151617181920
21222324252627
2829301234
567891011

View posts in large calendar