Internet Explorer (IE) の「インターネットオプション」の「詳細設定」タブで、「HTTP 1.1 を使用する」のチェックを外すと、Ajax Control Toolkit が動かないという話の紹介です。（プロキシサーバー経由になる場合は「プロキシ接続で HTTP 1.1 を使用する」のチェックを外す）

ググって見つけた CodePlex のページ ToolkitScriptManager ignores accept-encoding http header を読んで原因がわかりました。

簡単に言うと、原因は、ToolkitScriptManager が常に gzip で圧縮したスクリプトファイルを送信するのに、IE は「HTTP 1.1 を使用する」にチェックを入れないと解凍しないことです。

詳しく書くと、以下の通りです。

1. ToolkitScriptManager は、Microsoft Ajax Library を外部スクリプトファイルとして HTTP ハンドラ経由でブラウザにダウンロードさせるため、script 要素の src 属性に ScriptResource.axd?d=...&t=... と設定した初期ページをブラウザに返します。
   
   クエリ文字列のパラメータ d には、HTTP ハンドラが取得すべきファイルの指定と、送信時に圧縮するか否かの指示が含まれています。（パラメータ d, t の詳細については MSDN マガジンの ASP.NET AJAX アプリケーションの国際化 を見てください）
2. IE の設定で「HTTP 1.1 を使用する」にチェックが入っている場合、要求ヘッダには Accept-Encoding: gzip, deflate が含まれます。チェックを外すと Accept-Encoding は含まれなくなります。
   
   ASP.NET 標準の ScriptManager の場合は、Accept-Encoding の有無を見て、初期ページに指定される ScriptResource.axd?d=...&t=... のパラメータ d を変えてきます。（Accept-Encoding が無ければ非圧縮、Accept-Encoding: gzip, deflate が含まれれば gzip 圧縮がパラメータ d に指定される）
3. ところが、Ajax Control Toolkit の ToolkitScriptManager の場合は、要求ヘッダに Accept-Encoding があってもなくても、初期ページに指定する ScriptResource.axd?d=...&t=... は同じです。パラメータ d は gzip 圧縮の指定となります。
   
   つまり、IE の設定で「HTTP 1.1 を使用する」のチェックを外しても/外さなくても、サーバーからHTTP ハンドラ経由で受け取るスクリプトファイルは gzip で圧縮されたものになります。
4. 一方、IE の設定で「HTTP 1.1 を使用する」のチェックを外すということは、IE では圧縮ファイルは解凍されないということを意味します。（応答ヘッダに Content-Encoding: gzip が含まれていても無視されます）。
5. 結果、IE は Microsoft Ajax Library のスクリプトを解析できず、Ajax Control Toolkit が動かないということになります。（「文字が正しくありません。」とか「'Sys' は宣言されていません。」などのエラーが出ます）

IE8, IE9 で検証してみましたが、同じ問題が出ます。

いまどき「HTTP 1.1 を使用する」のチェックを外すことはないでしょうから実際に問題が出ることはなさそうですが、こういう問題もあるということは ASP.NET Web アプリケーションの開発者なら知っておいたほうがよさそうだと思って書いてみました。

SQL Server の「既定のインスタンス」のインスタンス名は何でしょうか？

下の画像を見てください。「既定のインスタンス」としてインストールした SQL Server 2005 Developer Edition のインスタンス名を Transact-SQL の SERVERPROPERTY 関数で取得した結果です。結果は MSSQLSERVER ではなく NULL になります。

MSDN ライブラリ SERVERPROPERTY (Transact-SQL) によると、既定インスタンスの場合 NULL になるそうです。上の画像の通りですね。つまり「既定のインスタンス」には名前はないということのようです。

ちなみに、デフォルト設定でインストールした Express 版（「名前付きインスタンス」になる）で同様にインスタンス名を取得すると、結果は期待したとおり SQLEXPRESS になります。

SQL Server Management Studio で調べることもできます。［オブジェクトエクスプローラー］⇒［サーバーのプロパティ］⇒［接続のプロパティ］と進んで、その画面の「インスタンス名」欄を見ると、既定のインスタンスの場合は以下の画像のように空白になっているはずです。

という訳で、実験では、「既定のインスタンス」には名前はないという結果になりました。

ところが、それを裏付ける文書が見つかりません。唯一見つけたのが、MSDN ライブラリ 名前付きインスタンスの使用 で、"インスタンスには、既定のインスタンス (名前が指定されていないインスタンス) と名前付きインスタンスがあります。"（英文では "An instance is either the default, unnamed instance, or it is a named instance. "）と書いてあります。

逆に、「既定のインスタンス」のインスタンス名は MSSQLSERVER という記述はいたるところで目にします。例えば、MSDN ライブラリ インスタンスの構成 には "既定のインスタンス名は MSSQLSERVER です。"（英文では "The default instance name is MSSQLSERVER."）とはっきり書いてあったりします。

多数決（笑）だと、後者（名前は MSSQLSERVER）に軍配が上がるようですが、実際どっちが本当なんでしょう？

自分は前者（名前はない）が正しく、MSSQLSERVER というのはサービス名であって、インスタンス名ではないと勝手に思っています。

----- 2012/11/18 追記 -----

試しに「既定のインスタンス」にインスタンス名 MSSQLSERVER を指定して接続にトライしてみました。"接続文字列が有効ではありません [87]" というエラーメッセージが出て接続に失敗します。

左のサムネイル画像をクリックすると原寸大の画像が表示されますので、エラーメッセージの詳細などはそれを見てください。

原寸大の画像の上のほうに示されているように、コンピュータ名 (papiko-pc) のみを指定した場合は接続に成功します。

という訳で、やはり「既定のインスタンス」にはインスタンス名はないのではと思います。

SQL Server の Express 版をインストールすると、デフォルトでは「名前つきインスタンス」となり、インスタンス名は SQLEXPRESS になります。

知ってました？　実は、自分は勘違いしていまして、SQLEXPRESS は Express 版の「既定のインスタンス」の名前だとばかり思っていました。（汗）

そうではなくて、一台のコンピューターにインストールできる「既定のインスタンス」は一つだけで、通常版/Express 版を問わず無名になるそうです。

時々 MSSQLSERVER という名前を目にしますが、どうやらそれはサービス名で、インスタンス名ではなさそうです。ちなみに、「名前つきインスタンス」のサービス名は MSSQL$<インスタンス名> になります。

詳しくは以下のページが参考になると思います。

名前付きインスタンスの使用

Windows サービス アカウントの設定

SQL Server 2012 Express のインストール

「既定のインスタンス」と「名前つきインスタンス」の主な違いは、名前の有無の他に、TCP/IP を利用してのリモート接続の際にポートが固定 (TCP 1433) になるか動的になるかです。

「名前つきインスタンス」の場合は、SQL Server の起動時に使用可能なポートが動的に割り当てられるので、接続には SQL Server Browser が必要になります。

ただし、「既定のインスタンス」が存在しなければ、Express 版を「名前付きインスタンス」SQLEXPRESS としてインストールしても、固定ポート (TCP 1433) を使うように設定を変更すれば SQL Server Browser を使用せずに接続することができます。

その場合、気をつけなければいけないのが接続文字列で、プロバイダに SqlClient を使用し SQLEXPRESS という名前の「名前つきインスタンス」に接続する場合は以下のいずれかに設定します。（2015/7/25 誤記訂正）

Data Source=tcp:<server name>
Data Source=tcp:<server name>,1433
Data Source=tcp:<server name>\SQLEXPRESS,1433

ちなみに、Data Source=tcp:<server name>\SQLEXPRESS とするとエラーになります。その理由は、サーバー名\インスタンス名で接続をした場合には、UDP 1434 (SQL Browser サービス) に接続して、指定したインスタンス名のポート番号を取得し、その後対象ポートに接続をする動作になるからだそうです。

また、プロバイダが Microsoft OLE DB Provider for SQL Server の場合、Data Source=tcp:<server name> ではエラーになるという報告もありますので注意してください。

詳しくは MSDN Forum のスレッド「SQLServer2008Expressにリモート接続できない」の Masayuki.Ozawa さんの書き込みを見てください。

Express 版のリモート接続のための設定は以下のページが参考になると思います。

SQL Server 2008 Express にリモート接続

上のページに、"リモート接続の場合、Windows 7/Vista では、Windows 認証を利用することはできません。" とありますが、Active Directory ドメイン環境でドメインアカウントを使用すれば Windows 認証は使用できます。

ワークグループ環境でも、以下のページに書いてある設定をすれば Windows 認証が使えるそうです（未検証です）。

ワークグループ環境にあるSQL SERVER 2005 EXPRESSでWINDOWS認証を使ってネットワーク接続する際の注意点

上の記事がリンク切れになると困るので、要点だけ書いておくと、サーバー / クライアント両方に同一 Windows ユーザーアカウントを設けて SQL Server の認証・承認の権限を与えるのはもちろん、ファイルの共有を無効にしておくことだそうです。（共有を有効にすると、サーバーに Guest としてアクセスしているとみなされるからだそうです。XP の話なので、Vista, 7, 8 でも同じかどうかは不明です）