Infopath の（受信）データ接続の限界は数百行。GetListItem は使えない。
Infopath の便利な機能に「データ接続」があります。「データ接続」には「送信」と「受信」がありますが、今回は「受信」の話です。
これは、外部データを参照するクエリを、GUI ベースで簡単に設定できるものです。
参照先としては、SQL DB、Access DB、Xmlファイル、Webサービス、SharePointリスト、ライブラリの情報が利用できます。
この機能はかなり優れていて、動作規則とセットで活用することで、任意のタイミングで、必要なデータをフォームに読み込ませることが可能です。
特に、SharePoint のリストを「簡易マスタ」として利用できるのが便利で、マスタのメンテナンスをエンドユーザに任せることが出来ます。
ただし、あくまで簡易設定の為、この機能には、いくつか無視できない制約があります。
そのひとつが「データを全て受信してしまう」点です。
Infopath のデータ接続は、必ず、接続先にある情報（の指定した列）を全て読み込みます。
いわゆる where 句的に「条件に合致するレコードのみ読込む」ことができません。
このため、社員マスタや顧客台帳など、件数の大きい情報に接続しようとすると、ネットワークおよびクライアントに、大きな負荷がかかることになります。
私の経験上、データ接続から取得できるレコードの上限は（実用性という意味で）500行前後です。
1000行を越えると非常に厳しい。
さらに10000行にもなると、もう無理です。
最初は、SharePoint のリスト/ライブラリからデータを取得するから遅いのかも？とも考えたのですが、プレーンな XML ファイルを読込んだ場合でも、大差はありませんでした。
この限界に対する対処方法は…、実はあまりありません。
1.コードに直接 SQL 文を書いて、受信データを絞りこむ。
2.コードで、SharePoint 標準の Web サービス経由でデータにアクセスし、受信データを絞りこむ。
3.専用のデータ取得 Web サービスを開発する。
こんなところでしょうか。
上限が増やせないなら、なんとか取得する情報を減らそう、というアプローチになります。
ところで、ここで疑問に思われた方もいらっしゃるかもしれません。
2番の「SharePoint 標準の Web サービス経由でデータにアクセス」が出来るなら、その Web サービスにデータ接続すれば良いのではないか？と。
確かにそうなんです。私もそう考えました。
SharePoint には、プログラムからリストを操作する為の Web サービス List.asmx があります。
URL は、http://server/_vti_bin/Lists.asmx です。
その中の GetListItems は、リストから条件に合致するアイテムを抽出するメソッドです。
Infopath のデータ接続ウィザードから、上記の URL にアクセスすると、一覧が表示されます。
GetListItems を選択すると、サンプル値の入力を求められます。
指定できる項目はサイト名、リスト名、ビュー名、列名、クエリ値。
確かにこれなら、必要な情報のみを取得できそうです。
しかし。このサンプル値にどんな値を入れようとも（或いは入れなくても）、エラーが返り、データ接続を作成することができません。
結論：Infopath のデータ接続は、GetListItems を利用できない。
Infopath は、GUI で指定されたパラメータから、自動的にクエリ文を生成しますがが、この GetListItems については、要求されるクエリ構文が特殊なため、Infopath では対応できないようですね。
む～、残念です。
この GetListItems を Infopath から利用できるように中継（？）してくれる Web サービスがあれば、実用性は高いと思うんですけどね。
SharePointのGetListItemsを使ってみました
SharePointのLists.asmxのGetListItemsの条件句XML
MSDN GetListItems メソッド
InfoPath から Web サービス ( Share Point 標準 ) を使用する方法について
中村 和彦（
AGENT: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.1; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
この機能\、確かに便利なのですがちょっとおしいですよね。
リストアクセスのための汎用的なWebサービスを開発するかどうか迷った挙句、取得行数が100行程度だったこともあり、データ接続を使用し、絞り込みとソ\ートをJScriptで実装することにしました。
経費申\請のワークフローで、所属部署ごとに申\請可能\な費目が決まっているため、これをリストライブラリで管理し、申\請部署決定時に自部署の費目を取得し繰り返しテーブルにセット、申\請者は数値のみ入力すればよいといったフォームを開発しています。
もうひとつ残念なのは、セカンダリデータソ\ースに取り込まれる受信データのリスト名・フィールド名が物理名ではなく表\示名となってしまうこと。
現在携わっている仕事では、リスト名やフィールド名、サイト列などの定義時、いったんアルファベットの英語名で定義を行った後、日本語の名称に変更しています。
こうすることで、見た目上は日本語で表\示しつつも、サイト列にアクセスするようなプログラムからは１バイト文字でアクセスするということを実現していました。
しかし、データ接続（受信）を使用して取り込まれたリスト名・フィールド名は、表\示名で取り込まれてしまうため、前述の絞り込みやソ\ートのロジックに日本語のフィールド名が登場する結果となりました。
表\示名を変更すると、プログラムへ影響が出てしまうし、名称に依存しないコーディングをすると分かりずらく列の順番に依存したコーディングになってしまうし、悩ましいです。
AGENT: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2
参照先にSQLが使えるのであれば元データが数万でも表\示が100位で有れば対応可能\かもしれないです。。
自部署で申\請可能\な費目が決まっている場合、個人マスタの運用が必要ですが、SQLのストアドプロシージャで実装が可能\です。
ストアドで下記の様に実装すればよいと思います。
１．アクセスしてきたユーザー名を取得
２．ユーザー名を元に部署を判断
３．部署に許された費目一覧をストアドで返す、
上記のストアドにセカンダリデータソ\ースで接続すれば良いと思います。
私の旧Blogですが、、
InfoPathとSQLストアドで自動採番を実装しています。
同様にストアドで自部署の費用一覧を取得する仕組みは作成できると思います。
http://sharepointdev.spaces.live.com/blog/cns!EE161CBDDAD9C711!1453.entry
AGENT: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; InfoPath.2; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; Sleipnir/2.8.5)
mariaさま、やまちゃんさま、コメントありがとうございます。
＞もうひとつ残念なのは、セカンダリデータ
＞ソ\ースに取り込まれる受信データのリスト
＞名・フィールド名が物理名ではなく表\示名
＞となってしまうこと
あ、言われて見ればそうですね。
これまで意識していませんでした。
しかし、ということは、後からマスタ側の列名を変更すると、データ接続が壊れる、ということなんでしょうか？
それは困るな〜。
ちょっと検証してみないといけないですね。
＞参照先にSQLが使えるのであれば元データ
＞が数万でも表\示が100位で有れば対応可能\
＞かもしれないです
そこなんですよね。
実のところ、突き詰めて行くと、Infopath は SharePoint と連携させるよりも、SQL のフロントエンドとして利用した方が、活用の幅が広かったりします（苦笑）
以前参加した、セミナでは、MVPの「ホチキス先生」もそういう使い方をされてましたね。
次の2010では、せめて GetListItems は使えるようになっていて欲しいなぁ・・