SQL Server

Microsoft TechEd 2010 ライトニングトーク「InfoPathとともに使うSQLServerの様々な機能」フォロー - 03

ホチキス先生 — Thu, 16 Sep 2010 20:42:00 GMT

データに対してまとまった処理を行うためにSQL Serverにストアドプロシージャを作ります。ではInfoPathからストアドプロシージャを実行する方法があるでしょうか。InfoPathのデータ接続はSQL文を自由に書けるので、ストアドプロシージャの実行も可能なように思えます。データ接続を編集すればいいはずです。まずSQL Serverにストアドプロシージャを作りましょう。

(slide.15 SQL Serverに作ったストアドプロシージャの例)

---------------------------------------------------------

create procedure テストプロシージャ

update テスト set 氏名 = '松本　吉生' where 学年 = 2

---------------------------------------------------------

上のcreate文で生成するストアドプロシージャは、「テスト」テーブルのデータのうち、学年が2年のデータの氏名を全部「松本　吉生」に変更するストアドプロシージャです。InfoPathからこのストアドプロシージャを実行できるようにデータ接続を作りましょう。データ接続ウィザードによってInfoPathで新しいデータ接続を作り、データ接続ウィザードの最終場面で、SQLの編集によってストアドプロシージャを実行するSQL文に書き換えるのです。

(slide.16 データ接続ウィザード1)

(slide.17 データ接続ウィザード2)

(slide.18 データ接続ウィザード3)

(slide.19 データ接続ウィザード4)

(slide.20 データ接続ウィザード5)

上のスライド20のステップでは、とりあえず適当なデータ接続またはテーブルを選んでおきます。

(slide.21 データ接続ウィザード6)

とりあえず仮のデータ接続ができました。では「SQLの編集」ボタンをクリックしてSQL文を書き換えましょう。

(slide.22 データ接続ウィザードの最後でSQLの編集を行う)

「SQLの編集」ボタンをクリックすると、ウィザードで自動的に生成したSQL文が表示されます。これをストアドプロシージャを実行するSQL文に書き換えます。書き換えた後、SQL文に誤りはないか、実行できるか、をチェックするために「SQLステートメントのテスト」ボタンで調べます。

(slide.23 データ接続を書き換えるSQL文)

ここで書き換えるSQL文は上のスライド23のようなものです。ストアドプロシージャを実行するにはexecute文だけでよいのですが、InfoPathのデータ接続はselect文以外のものを書くと、InfoPathがエラーと判断してしまいます。そこでまずset nocount onコマンドを書き、ダミーのselect文を書き、そのうえでexecute文を書くようにするのです。

(slide.24 InfoPathフォームにボタンを作りストアドプロシージャを実行するデータ接続を実行する1)

ストアドプロシージャを実行するexecute文を書いたデータ接続ができたら、フォームにボタンを作ります。ボタンのプロパティで「動作規則」をクリックします。

(slide.25 InfoPathフォームにボタンを作りストアドプロシージャを実行するデータ接続を実行する2)

ボタンのプロパティで「動作」としてexecute文を書いたデータ接続を使用してクエリを送信する、とします。クエリを送信するとデータ接続に書いたexecute文がSQL Serverに渡され、ストアドプロシージャが実行するようになります。

（前の記事）Microsoft TechEd 2010 ライトニングトーク「InfoPathとともに使うSQLServerの様々な機能」フォロー - 02

http://sqljp.com/hotikisu/archive/2010/09/11/27097.aspx

Microsoft TechEd 2010 ライトニングトーク「InfoPathとともに使うSQLServerの様々な機能」フォロー - 02

ホチキス先生 — Sat, 11 Sep 2010 18:43:00 GMT

InfoPathのフォーム作成でデータ接続先をSQL Serverにしたとき、データ接続ウィザードによってデータ接続を作ることができます。

(slide.04 InfoPathのデータ接続ウィザード1)

(slide.05 InfoPathのデータ接続ウィザード2)

(slide.06 InfoPathのデータ接続ウィザード3)

(slide.07 InfoPathのデータ接続ウィザード4)

(slide.08 InfoPathのデータ接続ウィザード5)

上のスライド08のステップでは、とりあえず適当なデータ接続またはテーブルを選んでおきます。

(slide.09 InfoPathのデータ接続ウィザード6)

InfoPathのデータ接続ウィザードを行うと、上のスライド04から09のようにデータ接続を作成することができます。ここで「SQLの編集」ボタンをクリックすると、ウィザードによって生成した接続用のSQL文を編集することができます。「SQLの編集」によって次のスライドのようなSQL文を書きます。

(slide.10 InfoPathのデータ接続ウィザードで「SQLの編集」を行う)

「SQLの編集」では自由にSQL文を書くことができます。しかしInfoPathは、SELECT文以外を書くとエラーになってしまうので、「set nocount on」を実行し、ダミーのセレクト文を書いてから必要なSQL文を書くことにします。書いたSQL文がエラーにならないことを「SQLステートメントのテスト」ボタンをクリックして確かめるとよいでしょう。

(slide.11 InfoPathのデータ接続ウィザードで「SQLの編集」を行い記述したSQL文)

実行したいSQL文の本体はUPDATE文です。ここで使う「テスト」テーブルには、生徒の氏名や年齢などのデータが入っています。この「テスト」テーブルのデータに対して、学年が「1」年の生徒データの氏名を全部「松本吉生」に変更する、というUPDATE文になります。データ接続には以下のように記述します。

------------------------------------------------------------

set nocount on

select 'dummy'

update テスト set 氏名 = '松本吉生' where 学年 = 1

------------------------------------------------------------

このようにして実行したいSQL文をInfoPathの「データ接続」として作成します。ではこれをInfoPathフォームから実行するにはどうすれば良いでしょう。それはInfoPathのフォームで「ボタン」を作り、ボタンの動作に「データ接続を利用してクエリを送信する」とすればよいのです。

(slide.12 InfoPathのフォームでボタンを作り「クエリの送信」を動作に設定する1)

(slide.13 InfoPathのフォームでボタンを作り「クエリの送信」を動作に設定する2)

(slide.14 InfoPathのフォームでボタンを作り「クエリの送信」を動作に設定する3)

このようにしてボタンを作れば、ボタンをクリックすることでクエリが送信され、UPDATE文を実行することができます。

（前の記事）Microsoft TechEd 2010 ライトニングトーク「InfoPathとともに使うSQLServerの様々な機能」フォロー - 01

http://sqljp.com/hotikisu/archive/2010/09/11/27096.aspx

（続き）Microsoft TechEd 2010 ライトニングトーク「InfoPathとともに使うSQLServerの様々な機能」フォロー - 03

http://sqljp.com/hotikisu/archive/2010/09/16/27102.aspx

Microsoft TechEd 2010 ライトニングトーク「InfoPathとともに使うSQLServerの様々な機能」フォロー - 01

ホチキス先生 — Sat, 11 Sep 2010 16:12:00 GMT

Microsoft TechEd 2010 ライトニングトーク「InfoPathとともに使うSQLServerの様々な機能」について、スライドを使いながらふりかえってみる。

(Slide.01 InfoPathはXMLオーサリングソフトなのか)

MicrosoftのOffice製品情報のページには「Microsoft InfoPath 2010 は、ビジネスプロセスの合理化に役立つ、フォーム作成およびデータ収集のためのツールです。」といった説明があります。この説明は少しわかりにくいですが、Wikipediaによると「マイクロソフトが開発・販売しているXMLオーサリングソフトである。」とあり、その他の技術ページでもおおむね「XMLオーサリングソフト」といった記述が見られます。これはInfoPathの基本的な一面をあらわしていますが、それだけではありません。InfoPathはデータ接続を利用してSQL Serverなどのデータベースに接続することができ、データベースサーバーに対するクライアントアプリケーションとして利用できるのです。InfoPathはドロップダウンリストボックスやラジオボタンなどのリッチなコントロールを使い、動作規則や条件付き書式、データの入力規則など豊富な機能を使ってノンコードでデータ入力フォームを作ることができます。つまり、SQL ServerとInfoPathを組み合わせると、クライアントサーバー型のデータベース業務アプリケーションを構築することができるのです。

(slide.02 InfoPathとSQL Serverによるクライアントサーバー型データベースシステム概要)

InfoPathとSQL Serverで構築したクライアントサーバー型データベースアプリケーションはこのような構成になります。データベースはSQL Server、クライアントコンピュータにはInfopath、そしてユーザー管理のためにActive Directoryを使います。データベースの個々のデータを参照したり、登録、修正の業務は、InfoPathを使って行いますが、システム管理にはどうしても「一括操作」といった場面があります。テーブルの全部のデータをある値で更新したい、ある条件のデータに対して特定の更新業務を行いたい、ある基礎データから別のデータを一括で作成したい、といった場面です。このような一括処理はInfoPathだけではできません。そこでSQL Serverが持っている機能を使うことになりますが、SQL Serverの中で動く仕掛けを作ったときに、InfoPathからどのようにコントロールのかを知る必要があります。

(slide.03 SQL Serverでデータを一括して処理する方法)

データを一括して処理する方法には色々ありますが、InfoPathからコントロールできる手法としては、次のようなものが考えられます。まず「データ接続にクエリを書く」方法があります。InfoPathのデータ接続には、直接SQL文を書くことができるのです。次に「ストアドプロシージャ」を使う方法があります。SQL Serverにストアドプロシージャを作り、その実行をInfoPathからコントロールします。また「トリガ」を使う方法もあります。そして「ジョブ」を使う方法があります。

（続き）Microsoft TechEd 2010 ライトニングトーク「InfoPathとともに使うSQLServerの様々な機能」フォロー - 02
http://sqljp.com/hotikisu/archive/2010/09/11/27097.aspx

Microsoft TechEd 2010 レポート - Day 3 - 1 - T1-402「既存業務システムのWindows Azureへの移行」

ホチキス先生 — Sat, 28 Aug 2010 20:09:00 GMT

クラウドコンピュータの波がやってきて、既存のITシステムは大きな見直しを迫られている。社内で独自に構築された「オンプレミス」システムなのか、ネットワークに展開されたクラウドシステムなのか、どちらかを選択しなければならない時代になった。とりわけコスト削減の要求が厳しくなり、クラウドの利用を積極的に考えなければならない。

クラウドコンピューティングが現れはじめたとき、その期待から全てのシステムをクラウドに置くということが言われた。しかし現実にはそうでなく、自社内の「オンプレミス」なシステムとクラウドの両方を組み合わせることが現実解となっている。ではオンプレミスとクラウドの使い分けをどう考えればよいのだろうか。ここで業務システムを3つのタイプに分類して考える。

まず、金融などミッションクリティカルな業務システムである。これはクラウドには不向きである。それは、クラウドでは性能保証が難しく、可用性用件が非常に難しい、自社でのデータ保有や管理の要件があることが多い、などの理由からだ。具体的には可用性の面では、クラウドでは99.9%しかない。次にクラウドならではの新しいタイプのシステムとして大規模分散計算処理の分野がある。モンテカルロ法などシミュレーション、大規模ログ解析、統計分析、学術計算領域など、伸縮自在性を生かせる領域で強みを発揮する。しかし現実はこれら両極端な業務形態に分けられるものばかりではない。

三番目のものとして、従来からある業務システムがある。たとえば簡単な.NETアプリケーションはほぼそのままAzureに移行できるだろう。しかし本当にそんなに簡単に移行できるのだろうか、という声はよく聞かれる。たとえばデータセンターは現状では海外にしかない、可用性が一律99.9%の設定である、ストレージの容量制限がある、などだ。だがこれらの問題は、実際に使ってみないとわからない。クラウドコンピューティングのメリットは魅力だが移行してよいのか、移行できるのかという悩みがある。しかし今日の技術進歩を念頭におくと、クラウド技術の発展は急激におこっている。今できることが半年たっただけで急激に広がることは間違いないだろう。

クラウドの技術革新については、VM RoleとWindows Azure Platform Applianceという2つのキーテクノロジーが出てくると状況はかなり変わるだろう。VM RoleはIaas型に近いクラウドサービスの提供で、自由に環境を変えることができる、仮想マシン環境を提供するものである。Windows Azure Platform Applianceは、AzureをMicrosoftだけでなく、「プロバイダのAzure」や「自社内のAzure」といった形態も提供できるものだ。これによって地理的に近い場所での利用、物理的なAzureの制御、データの保有などが可能になる。

これらの見通しの中で、では、今、何をやるべきだろうか。それは「まず使ってみる」ことである。クラウドは進展が早く、現時点では適用できない領域が、半年、一年、数年後には大きく変化し、適用できる領域が大きく広がる可能性がある。また可用性が99.9%という数値があるが、では月あたり43分もシステムが止まるのか、と思うととても使えないと思うかもしれないが、実際はシステムが停止するわけではない。むしろパッチを当てることも止めることなくできる。つまり机上の検証では実感できないことが多く、その意味でも実際に使ってみる必要が大いにある。いざ導入が目前になり、検証を行うのでは遅すぎることになる。

クラウド化で何が変わるのか。たとえばツールの使い方などは技術資料を見ながら学べばよい。しかしクラウドの概念、設計やアーキテクチャの考え方のパラダイムシフトが必要になる。パラダイムシフトのポイントは3つにまとめられる。まずデータストレージ選択の考え方、次にオンプレミスとクラウド連携の考え方、三つ目に運用監視の考え方である。

まずデータストレージだが、クラウドになって最も厄介なものはデータベースの移行だ。RDBMSの基本思想は「一事実一ヶ所」である。オンプレミスのデータベースはスケールアップが基本だが、クラウドではスケールアウトを考え、この思想は全く反対だ。クラウド環境では「機能」「容量」「価格」の3つを同時に満たすことは不可能だ。たとえばオンプレミスのデータベースでは、サーバーの性能を良くすることで「機能」と「容量」の両方を高めることができるが、この場合は「価格」を下げることはできない。クラウドではSQL AzureデータベースサービスとWindows Azureストレージサービスがあり、前者は「機能」は高いが「容量」は50GBまでの制限がある。後者は「機能」は低いが容量は大きく使える。そこでデータをAzureにおくときは、業務データはSQL Azureデータベースサービスにおき、ログなど大量に蓄積する必要のあるものはWindows Azureストレージサービスに置くといった使い分けを考える。もし業務データの規模が大きく、SQL Azureデータベースの容量制限をクリアしたい場合は、データベースの水平分割が必要である。

オンプレミスとクラウドの連携をするときは、「データ連携」「処理連携」「認証連携」「運用連携」の4つの考え方が必要だ。「データ連携」ではマスタデータの同期が必要である。「処理連携」ではAppFabricサービスパスを活用したシステム間連携、「認証」ではADシングルサインオンを実現するフェデレーション認証がある。AppFabricサービスパスとフェデレーション認証は連携に関するキーテクノロジである。AppFabricサービスパスは、オンプレミス側とクラウドからの両側からAppFabricサービスパスへの接続を張るもので、オンプレミスとクラウドのデータ連携を行うために、オンプレミス側のファイヤーウォールの受信ポートを解放する必要がない技術だ。フェデレーション認証はAzure上のシステムに社内ADアカウントでシングルサイオンのログインができる技術だ。

運用監視考え方がクラウドでは大きく変わる。オンプレミスの運用では管理者はアプリケーションからミドルウエア、インフラまで全部を対象としている場合が多いと思われるが、クラウドではミドルウエアとインフラの管理はMicrosoftにまかせればよい。管理者はアプリケーションの運用に専念できる。

Microsoft TechEd 2010 Japan 公式サイト
http://www.microsoft.com/japan/teched/2010/

Microsoft TechEd 2010 レポート - Day 2 - 3 - T4-304「Microsoft BIを支えるReporting Services & PowerPivot～松本美穂のすぐに使えるBIシステム構築の技～」

ホチキス先生 — Sat, 28 Aug 2010 19:58:00 GMT

最も最初のバージョンからMicrosoft SQL Serverにかかわっており、名著「SQL Server 2000でいってみよう」など多くの技術書の著者松本美穂女史によるセッション。

PowerPivot for Excelは、サーバー側の作りこみが不要な点がパワフル。インメモリアーキテクチャで高速なデータ処理が実現できる。64ビットCPUのパワーを十分に利用することができる。またExcelのデータ上限100万件を超えるデータも対応している。

PowerPivotの概要が説明されたあと、実際にデモが行われた。画面に表示されたExcelのブックには、なんと一千万件のデータが格納されている。さらにこのテーブルをスクロールするのも高速で、まったくストレスなく表示される。これはたいへんな驚きだ。またパワーピボットの表示もすごく早く、グラフの追加や描画の更新もとても速い。このようなパフォーマンスを得られるのは、すべてインメモリで実行しているからである。したがってコンピュータのメモリが小さいと、このPowerPivotのパフォーマンスの恩恵を得ることはできない。

PowerPivotで大量のデータを分析するとき、ExcelのPowerPivot自体は高いパフォーマンスで動作しても、データの更新には時間がかかるだろう。SQL Serverへの負荷もある。そこでPowerPivotを使う場合は、分析に必要なデータだけを選んで取ってくる設計をしなければならない。またデータベースの設計者としては、このようにユーザーがExcelで大量のデータを取れる時代になったことから、データベースのセキュリティにはこれまで以上に配慮しなければならないだろう。

PowerPivot for SharePoint 2010では、分析レポートの共有とセキュアなデータ格納、バックグラウンドでのデータ更新のバッチ処理、Excel ServiceによるWebブラウザベースの共有、などがあげられる。PowerPivot for SharePointをインストールすると、テンプレートとしてPowerPivot Siteができる。管理はPowerPivot管理ダッシュボードで行う。

SQL Serverの機能拡張はいろいろあるが、特にReporting Serviceは強力に進化している。特にSQL Server 2008 R2からは、Bingマップ連携、データバー、インジケーターなどデザイン面の拡張など大きく拡張された。このReporting ServiceによるBIシステムでは、共有データソース、共有データセット、共有レポートパーツを利用してレポート作成時間を短縮することができる。またレポートキャッシュまたはクエリキャッシュ、キャッシュの更新計画機能などキャッシュ機能を活用する。

Microsoft TechEd 2010 Japan 公式サイト
http://www.microsoft.com/japan/teched/2010/

SQL Serverのユーザー定義関数を使おう～（９）日付に関するユーザー定義関数を作る

ホチキス先生 — Tue, 15 Jun 2010 00:10:00 GMT

日付に関するユーザー定義関数を作った。この関数を作った目的は、今年度の範囲で処理をする場面が多かったので、「今年度の最初の日」と「今年度の最後の日」を知るユーザー定義関数を作ろうと思ったためだ。例えば日付が「2010年6月15日」だと、この日に対して「今年度最初の日」は「2010年4月1日」であり、「今年度最後の日」は「2011年3月31日」である。

2010年であっても、4月1日以前は前年度である。日付が「2010年3月15日」だと、この日に対して「今年度最初の日」は「2009年4月1日」であり、「今年度最後の日」は「2010年3月31日」なのだ。

そこでこの関数の中では、まず「日付」に対して「年度」を求めている。「年度」さえ判定できれば、その年の4月1日が「今年度最初の日」であり、次の年の3月31日が「今年度最後の日」である。

使い方は、select dbo.fx日付('2010/06/15','年度最初日')、のようにする。最初の引数が日付で、次の引数がパラメーターだ。パラメーターは「年度最初日」と「年度最後日」を実装しているが、これも拡張可能である。日付に関するいろいろな処理を一括してこの関数に盛り込もうと思ったので、パラメーターによって拡張可能にしている。

また、今日の日付で「今年度の最初の日」を求めたいなら、select dbo.fx日付(getdate(),'年度最初日')、にすることもできる。

-------------------------------------------------------------------------------------------------------

create function [dbo].[fx日付]
(
@P_日付 smalldatetime,
@p_パラメータ varchar(10)
)
returns smalldatetime
as
begin

declare @thisnendo int
declare @thisyear41 smalldatetime

/*年度の取得*/
set @thisyear41 = cast(cast(datepart(year,@p_日付) as varchar) + '/' +'4/1' as smalldatetime)
if @p_日付 >= @thisyear41
begin
set @thisnendo = datepart(year,@p_日付)
end
if @p_日付 < @thisyear41
begin
set @thisnendo = datepart(year,@p_日付)-1
end

/*今年度最初の日を求める*/
if @P_パラメータ = '年度最初日'
begin
return cast(cast(@thisnendo as varchar) + '/' +'4/1' as smalldatetime)
end

/*今年度最後の日を求める*/
if @P_パラメータ = '年度最後日'
begin
return cast(cast((@thisnendo + 1) as varchar) + '/' +'3/31' as smalldatetime)
end
return null
end

SQL Serverのユーザー定義関数を使おう～（８）生徒情報を取得するユーザー定義関数を作る

ホチキス先生 — Mon, 14 Jun 2010 23:33:00 GMT

システムを作っていくと、多くの場所で同じ処理をすることに気づく。例えば生徒の基本情報を記録する「生徒」テーブルには、生徒の氏名を「姓」と「名」のフィールドで記録している。しかし帳票では「姓＋名」で表示をしたいので、至る所で「姓＋'　'＋名」のような処理をすることになる。このような似たような処理はユーザー定義関数を作っておくとよい。

ここでは生徒基本情報である「生徒」テーブルから、学籍番号をキーにして生徒の情報を関数で取り出すものを作ってみた。

使い方はこうだ。生徒の姓名が欲しいときには「select dbo.fx生徒('1234567','姓名')」のようにする。最初の引数が学籍番号で、次の引数はパラメータだ。性別を知りたいときは「select dbo.fx生徒('1234567','性別')」のようにする。関数の作りは簡単で、パラメータによってif文で条件分岐しているだけである。

この関数はパラメーターを増やすと改正可能である。増やす分には既に作ったクエリやストアドプロシージャに影響を与えない。

------------------------------------------------------------------------------------------------

create function [dbo].[fx生徒]
              (
              @p_学籍番号 char(7),
              @p_種類 varchar(50)
              )
returns varchar(50)
as
begin
              if @p_種類= '姓名'
              begin
                            return (SELECT 生徒姓+ '　' + 生徒名 FROM dbo.生徒 where 学籍番号 = @p_学籍番号)
              end
              if @p_種類= '姓'
              begin
                            return (SELECT 生徒姓 FROM dbo.生徒 where 学籍番号= @p_学籍番号)
              end
              if @p_種類= '名'
              begin
                            return (SELECT 生徒名 FROM dbo.生徒 where 学籍番号= @p_学籍番号)
              end
              if @p_種類= '性別'
              begin
                            return (SELECT dbo.kbn_性別.区分名 FROM dbo.生徒                                                        INNER JOIN dbo.kbn_性別 ON dbo.生徒.性別 = dbo.kbn_性別.区分コード                                                        where dbo.生徒.学籍番号 = @p_学籍番号)
              end
              if @p_種類= '性別コード'
              begin
                            return (SELECT 性別 FROM dbo.生徒 where 学籍番号= @p_学籍番号)
              end
return null
end

SQL Serverのユーザー定義関数を使おう～（７）講座情報を取得するユーザー定義関数を作る

ホチキス先生 — Thu, 04 Feb 2010 04:08:00 GMT

ユーザー定義関数の便利さがわかってくると、頻繁に行うクエリは関数にしてしまうと便利なことに気づく。また便利であるとともに、複雑なクエリを作ったときでも構造がシンプルになり見やすくなるメリットもあるだろう。

たとえば本校のシステムでは、毎年の授業講座について「年度」、「受講登録番号」、「講座展開番号」の3つのコードで管理している。ある年度について、各曜日の時間帯に設定した講座を受講登録番号に割り当て、同時間帯に複数の講座に分割して実施する場合は異なる受講登録番号を割り当てる。この3つのパラメーターで講座が決定される。

そこで「年度」、「受講登録番号」、「講座展開番号」の値から、その講座の詳細情報を得られるユーザー定義関数を作る。関数の引数は、「年度」、「受講登録番号」、「講座展開番号」の3要素に加えて何を返すのかを指定する「パラメーター」の4つとする。パラメーターは意味がわかるように「名称」、「教員」、「教員名」といったテキストで指定することにする。

使い方は例えばこのようになる。

＜その講座の授業担当者名を知りたいとき＞

select fx講座('09',123,'01','教員名')

＜結果＞

松本吉生

とりあえず取得したい要素を「講座名称」、「授業担当教員の職員番号」、「授業担当教員名」、「出欠登録をする教員の職員番号」、「出欠登録をする教員名」と考えた。このように作ったユーザー定義関数は、パラメーターを追加することで拡張することができる。

しかし注意点としては、一度実装してしまったユーザー定義関数、パラメーターなどを変更することは難しい。その関数がどこで使われているかを全て洗い出し、問題がないことを確かめてから変更しなければならない。システムの規模が大きくなると事実上変更することは不可能になると思って最初から吟味して実装することがいいだろう。

＜ユーザー定義関数を作るCREATE FUNCTION文サンプル＞

CREATE function [dbo].[fx講座]
/*
現在の講座の情報を返す関数。講座を決定する要素は、年度、受講登録番号、講座展開番号、パラメータ。返す値は、名称、教員コード、教員名、・・・など。varchar(50)、後に拡張できる要素を残しておく。パラメータは’名称’、’教員’、’教員名’、'出欠教員'、'出欠教員名'・・・とする*/
              (
              @p_年度 char(2),
              @p_受講登録番号 int,
              @p_講座展開番号 char(2),
              @p_パラメータ varchar(50)
              )
returns varchar(50)
as
begin
if @p_パラメータ = '名称'
              return (select koza_3_nm from c_k6 where kainendo_cd = @p_年度 and jyukotoroku_no = @p_受講登録番号)
if @p_パラメータ = '教員'
              return (select 教員番号 from c_k9 where kainendo_cd = @p_年度 and jyukotoroku_no = @p_受講登録番号 and bunkatsu_no = @p_講座展開番号)
if @p_パラメータ = '教員名'
              return (select 職員姓名 from 職員 where 職員番号 = (select 教員番号 from c_k9 where kainendo_cd = @p_年度 and jyukotoroku_no = @p_受講登録番号 and bunkatsu_no = @p_講座展開番号))
if @p_パラメータ = '出欠教員'
              return (select 出欠教員番号 from c_k9 where kainendo_cd = @p_年度 and jyukotoroku_no = @p_受講登録番号 and bunkatsu_no = @p_講座展開番号)
if @p_パラメータ = '出欠教員名'
              return (select 職員姓名 from 職員 where 職員番号 = (select 出欠教員番号 from c_k9 where kainendo_cd = @p_年度 and jyukotoroku_no = @p_受講登録番号 and bunkatsu_no = @p_講座展開番号))
return null
end

InfoPathとSQL Server－InfoPathのフォームを開いたときに今日のデータで自動的にクエリを行うには（２）セカンダリデータソースの場合

ホチキス先生 — Sat, 13 Jun 2009 11:46:00 GMT

InfoPathをSQL Serverに接続したとき、動的クエリを実行できるのはただ一つの「メイン接続」だけであり、それ以外のデータ接続は「セカンダリデータ接続」と呼ばれ動的クエリを実行することはできない。しかしデータ接続のSQL文を工夫することにより、いろんなデータ取得方法を設定できる。

たとえば、日付のフィールドがあり日々のデータが入っているテーブルに接続しているとしよう。セカンダリデータソースでは動的クエリができないので、単にウィザードでデータ接続を作るだけでは、全てのデータを一度に取得することしかできない。しかしSQL文を書き換えることによって、動的ではないにしても、ある一定のデータのみを抽出して取得することもできる。

例えば次のようなテーブルがあるとしよう。

テーブル名：日程
フィールド：日付 smalldatetime、内容 varchar(50)

このテーブルに対してInfoPathのデータ接続ウィザードでセカンダリデータ接続を作ると、次のようなSQL文が自動的に生成する。

select "日付","内容" from "dbo"."日程" as "日程"

一方、SQL Serverにはgetdate()関数があり、現在の日付と時間を取得することができる。

そこでSQL文をこのように変えれば、今日のデータだけを選択して取得するデータ接続になりそうに思う。

select "日付","内容" from "dbo"."日程" as "日程" where "日付" = getdate()

しかし「日付」フィールドに納められているデータは、例えば2009/06/13 0:00:00といったように、その日の0時00分00秒のデータとして生成しているだろう。しかしgetdate()で得られる値は日付と時間をあわせもっているので、クエリが合致せず何もデータを表示してくれない。

そこで少し工夫が必要である。getdate()で取得した日付と時間のうち日付の値だけを分離してしまうのだ。例えば次のようにデータ接続を変更する。

select "日付","内容" from "dbo"."日程" as "日程"where "日付" = (select cast(datename(year,getdate())+'/'+datename(month,getdate())+'/'+datename(day,getdate()) as smalldatetime))

上のSQL文では、getdate()で取得し日付と時間のうち「年」と「月」、「日」をdatename()関数で分離して取得し、繋ぎ合わせて日付のデータを作っている。

これでセカンダリデータソースでも「今日のデータ」だけを取得することができる。この手法は工夫によって応用ができ、SQL Serverの関数を使ってセカンダリデータソースでもいろんなデータ抽出を行うことができる。さらに「ユーザー定義関数」を作れば、より高度なクエリを行うこともできる。

なお、SQL Server 2008には日付だけのdate型が実装されているので、日付だけを扱いたいときはフィールドの型をdate型にしておくのがよいだろう。

InfoPathとSQL Server－InfoPathのフォームを開いたときに今日のデータで自動的にクエリを行うには（１）メイン接続の場合

ホチキス先生 — Sat, 13 Jun 2009 11:22:00 GMT

InfoPathのフォームを開いたとき、「クエリの実行」ボタンを押さなくても自動的に「今日」の日付のデータを表示させたいことがある。日々の定型入力などをしたいときなどだ。このとき、InfoPathの「today()」関数を使うことができる。

例えば「日付」のフィールドを「クエリフィールド」として、その「規定値」にtoday()関数をセットしておく。そして「フォームのオプション」の「開く／保存」の「開くときの動作」の「動作規則」に「クエリの実行」を設定しておけばいい。これでフォームを開いたとき、今日の日付で自動的に「メイン接続」でデータベースからデータを取得し、今日のデータが表示されたフォームが開く。

しかしセカンダリデータ接続では「動的クエリ」を行えない。またデータソースではInfoPathのtoday()関数を使うことができない。しかしセカンダリデータソースでも工夫によって「今日のデータ」を取得することができる。