データベースに接続しようとして "初期化文字列の形式が使用に適合しません。index x で始まっています。"（実際には x には数字が入ります）というエラーメッセージが出ることがあります。

「使用」って何？、「index」って何？・・・って感じで意味不明ですが、原文（英文）は次のようになっていて、これなら意味が分ります。

"Format of the initialization string does not conform to specification starting at index x"

つまり、接続文字列の x 文字目（0 から数えて）以降が、仕様（使用ではなくて）に適合しないということです。要するに接続文字列が間違っているということです。

例えば、接続文字列で Initial Catalog=Northwind の設定を間違えて以下のようにしたとします。

Data Source=.\SQLEXPRESS;Initial Catalog='Northwind ...

そうすると、上の画像のように "初期化文字列の形式が使用に適合しません。index 25 で始まっています。" というエラーがでます。'Northwind は間違いで、その ' は最初の文字 Data の D を 0 から数えて 25 番目です。

.NET 4 になって、「使用」の間違いぐらいは「仕様」に直したかと思って、調べてみましたが、間違ったままでした。

ただし、接続文字列の間違いが問題ではなくて、レジストリキーの修正が必要という話もありますので注意してください。

データベースの接続が出来ません

CustomValidator と RequiredFieldValidator について新発見（？）がありましたので、忘れないように書いておきます。

(1) CustomValidator

RequiredFieldValidator 以外では、未入力に対する検証結果は OK 扱いになると思っていましたが、CustomValidator の場合は例外がありました。

それは、.NET 2.0 で追加された ValidateEmptyText プロパティ を true にすることです。

ValidateEmptyText プロパティがデフォルトの false の場合は、RegularExpressionValidator や RangeValidator などと同様に、未入力の場合はその値を評価することなく、検証結果は OK 扱いになります。

ValidateEmptyText プロパティを true にすることにより、検証対象コントロールが未入力でも、CustomValidator は、プログラマが設定した検証ロジックを使用して検証対象のコントロールの値を評価し、検証結果を返します。

では、CustomValidator の ValidateEmptyText プロパティを true にして空白の検証を可能にし、RequiredFieldValidator を使わないで済ませられるかと言えば、機能的にはそれで問題なくても、ユーザビリティの面では問題がありそうです。

検証コントロールは、ユーザーに適切なエラーメッセージを提供するということも重要な目的の一つだそうです。検証条件が異なれば適切なエラーメッセージは異なるはずです。

検証コントロールのエラーメッセージは固定的なので、CustomValidator 一つで済ませる場合、エラーメッセージは "未入力もしくは入力形式がＸＸＸと異なります" とせざるを得ません。

それより、RequiredFieldValidator と CustomValidator を併用して、未入力の時は "未入力です" というエラーメッセージを、入力はあるが形式が違っている場合は "入力形式がＸＸＸと異なります" とした方がユーザーフレンドリーだと思います。

というわけで、結局、未入力の検証には、RequiredFieldValidator を使用するのが正解のようです。

なお、上記で言う「未入力」とは String.Empty だけではなくて、半角/全角スペースも含まれますので注意してください。実は、これも今回調べるまで知らなかったです。（笑）

あともうひとつ。CustomValidator がデフォルトで未入力でも検証 OK とするのには理由があります。それは、RequiredFieldValidator と併用した場合、未入力の際に 2 つのエラーメッセージが同時に表示されるのはユーザーにとって煩わしいからだそうです。

(2) RequiredFieldValidator

RequiredFieldValidator は「未入力」をチェックするものだと思っていましたが、正確にはそうではなかったです。

MSDN ライブラリに書いてあったのですが、実は、"入力コントロールに対する検証は、そのコントロールがフォーカスを失ったときに、その値が InitialValue プロパティ の値から変更されていない場合は失敗になります。" ということだそうです。

従って、MSDN ライブラリのサンプルコードにあるように、検証対象の TextBox の Text プロパティに "Enter a value" と設定しておき、RequiredFieldValidator の InitialValue プロパティにも同じ文字列 "Enter a value" を設定しておけば、ユーザーが初期値を変更しなかった場合に検証 NG とします。

InitialValue プロパティのデフォルト値は String.Empty、TextBox の Text プロパティもデフォルトで String.Empty なので、結果的に「未入力」の検証が可能になるということです。

なお、全角/半角スペースを入力しても検証 NG となるのは、MSDN ライブラリにも書いてありますように、"InitialValue プロパティと入力コントロールの両方の文字列は、検証が実行される前にその文字列の前後の余分な空白が削除されてトリムされます。" からです。

jQuery Ajax で Web サービスを呼び出し、xml 形式のデータを受け取る場合の話です。

まず、Web サービスのメソッドの戻り値の型の形式として XML を指定するときは、ScriptMethodAttribute 属性 を追加し、ResponseFormat プロパティ を Xml に設定します。さらに、メソッドが XmlDocument オブジェクト を返すようにします。以下のような感じです。

[WebMethod]
[ScriptMethod(ResponseFormat = ResponseFormat.Xml)]
public XmlDocument GetXmlDocument()
{
    // Xml 形式の文字列を組み立て。
    string _xmlString = CreateXmlString();

    XmlDocument xmlDoc = new XmlDocument();
    xmlDoc.LoadXml(_xmlString);
    return xmlDoc;
}

こうしておくと、XmlDocument オブジェクトはサーバーで Xml 形式の文字列にシリアル化され、このメソッドを呼んだクライアントに返されます。また、応答ヘッダには Content-Type: text/xml が含まれるようになります。

ScriptMethod 属性の ResponseFormat プロパティを Xml に設定しておかない場合、Web サービスのメソッドが返すデータの形式は、クライアントからの要求ヘッダの Content-Type の指定によるようです。

クライアントからサーバーへデータを送信する場合、要求ヘッダの Content-Type は、application/x-www-form-urlencoded または application/json のいずれかになるはずです（データを送信しない場合、Content-Type を指定しないこともありますが）。

前者は普通に form データをサーバーに POST する時のデータ形式、後者は Ajax でのデータ交換フォーマットのデファクトスタンダード（？）である JSON 形式です。

要求ヘッダの Content-Type が application/json となっている場合、ScriptMethod 属性の ResponseFormat プロパティを Xml に設定しておかないと、戻り値が Xml 形式にならない（といって、正しい Json 形式にもならない）ので注意してください。

要求ヘッダの Content-Type を設定しない、または application/x-www-form-urlencoded とした場合は、ResponseFormat プロパティの設定に関係なく、戻り値は Xml 形式になります。（ResponseFormat プロパティを Json 設定しても無視されて、戻り値は Xml 形式になります。）

クライアントで Web サービスからのデータを受け取るのは jQuery Ajax の success ハンドラです。jQuery Ajax は、サーバーからの応答ヘッダに含まれる Contetnt-Type を見て success ハンドラに渡すデータの形式を決めます。

jQuery API の解説ページ jQuery.ajax() に次の説明があります。

"The text and xml types return the data with no processing. The data is simply passed on to the success handler, either through the responseText or responseXML property of the jqXHR object, respectively."

上のサンプルに書いたコードの場合、Web サービスからの応答ヘッダに Contente-Type: text/xml が含まれますので、success ハンドラに渡される data は jqXHR.responseXML から取得されます。

jqXHR.responseXML は何かというと、MSDN ライブラリの responseXML property に書いてあるように、XML DOM オブジェクト（ただのシリアル化された文字列ではなく）になります。

シリアル化された文字列を表示したい場合は、IE であれば xml プロパティが使えます。詳しくは、MSDN ライブラリの IXMLDOMDocument/DOMDocument Members を参照してください。

ただし、xml プロパティは IE 専用なので、Mozilla 系のブラウザの場合は以下のように XMLSerializer を使用できます。

function getXmlDocument() {
  $.post("163-ScriptMethodAttribute.asmx/GetXmlDocument",
    function (data, textStatus, jqXHR) {
      $('#output').empty();
      $('#output').text(data.xml || 
        (new XMLSerializer()).serializeToString(data));
    }
  );
}

または、jqXHR.responseText から取得することも可能です。