SQL Serverでこんなこと。

PerlからADO

あきこ — Fri, 04 Jan 2008 09:44:00 GMT

最近、PerlからSQL Serverへの接続を行うコードを書いていたので、その覚え書きです。

実は、ストアドや.NET系のコーディングを始める前は、PerlやJavaがメインで、DB操作のためのSQLは、コードや設定ファイルの中に書くことが中心でした。(ただしOracleとかでした)

その後、SQL Serverを中心にお仕事をするようになってから、ストアドを多用するようになり、コードもC#などで書くようになっていきました。

さて今回、XML-RPCで外部APIと連携を行う必要が出たので、PerlでSQL Serverの操作を行うことになりました。（C#でもXML-RPCは実装可能だったのですが、私以外のメンテナーがいないので、同僚がメンテナンスしやすいPerlで行きましょう、ということになったのでした...）

ただ、私としては、できるだけ面倒なSQLはコードに書かず、サーバ側のストアドでカバーしたいというのが希望でした。同僚も、SQL(ストアド）の方は操作/修正には問題無いので、この方針で。

ストアドを使うメリットは、まずは、Perl中にSQLを書かなくて済むこと。（コード内で、@や\といった特殊文エスケープしたりするのが面倒なんですよね....）
同じストアドは（データ取得用ですけど）、ManagementStudioからも呼べるし、WebServiceでも呼び出せます。JavaのJDBCでも呼べますね。

さて、問題は、PerlのDBIで、SELECTステートメントを返すストアドをどう実行するか、ということと、複数SELECTの結果が返る場合、値をどうやって取得するかです。

どうやらDBI + ODBCだとうまくできません....。（というか、とんでもなく久しぶりなので、よく分らない）
かと言って、またもPerl中に長～いSQLは書きたくない。

一方、ADO .NETだと、SELECT結果は、複数STATEMENTも含め、DataSetというオブジェクトで返してくれるので、それぞれテーブル名や順番に取り出すことができます。（ここが、私が.NETのASPにしたいよ～と言った理由のひとつでした）

で、かなり時間がかかってしまったのですが、調べた結果、Win32::OLEを使うと、ADOを用できることが判明。

若干C#などで扱うのよりは面倒ではありますが、これでいくらか幸せになりました。

use strict;
use Win32::OLE;
use vars qw($dsn);

# Data Source Setting
$dsn = "driver=SQL Server;".
"Server=localhost;".
"database=TestDB;".
"Trusted_Connection=no;".
"AutoTranslate=No;";

# Connection Open
my $Conn = Win32::OLE->new("ADODB.Connection");
$Conn->{CursorLocation} = 3;? # the same as adUseClient
$Conn->{Open} = $dsn;

if (Win32::OLE->LastError() != 0) {
print "Failed creating ADODB.Connection object -> "
    . Win32::OLE->LastError();
exit 0;
}

my $Cmd = Win32::OLE->new("ADODB.Command");

if (Win32::OLE->LastError() != 0) {
   print "Failed creating ADODB.Command object -> "
       . Win32::OLE->LastError();
   exit 0;
}

my $Id;
my $ReferenceId;

####
# For Test
#
# 実際は、CGIのRequest Parameterやコマンドライン引数などから受け取ります。
#
###
$Id = 8;
$ReferenceId= 300;

# Command Execute
$Cmd->{CommandType} = 4; # Execute as Stored

# Prepared Statementを使わない場合はこんなかんじ。
$Cmd->{CommandText} =
    "dbo.getSampleData ($Id, $ReferenceId )";
$Cmd->{CursorLocation} = 3;
$Cmd->{ActiveConnection} = $Conn;

$Cmd->{Prepared} = 1;
$Cmd->{CommandTimeout} = 15;

my $rs = $Cmd->Execute();

if (Win32::OLE->LastError() != 0) {
    print "Failed opening ADODB.Recordset object for Command -> ". Win32::OLE->LastError();
    exit 0;
}

my $rs_count = $rs->{RecordCount};
print $rs_count . "\n";
if (!$rs_count) {
    print "Record not found to post or close.\n";
    exit 0;
}

print "\n------------1st SELECT Result-------------\n";
while ($rs->EOF != 1) {
    print "Id = ". $rs->Fields('Id')->{Value}."\n";
    print "Name = ". $rs->Fields('Name')->{Value}."\n";
      :
    $rs->MoveNext();
}

my $rs1 = $rs->NextRecordSet();

print "\n------------2nd SELECT Result-------------\n";
while ($rs1->EOF != 1) {
    print "ReferenceId = ". $rs->Fields('ReferenceId')->{Value}."\n";
    print "ProductName = ". $rs->Fields('ProductName')->{Value}."\n";

$rs1->MoveNext();
}
$rs->Close();
$Conn->Close();
exit 0;

Prepared Statementを使ってストアド実行時の引数を渡したい場合は、こんな感じ。

$Cmd->{Prepared} = 1;

#ストアドの戻り値を指定する場合　（Direction = 4）
$Cmd->Parameters->Append(
$Cmd->CreateParameter('@retval', 3, 4));

# ストアドへの引数はこちら
$Cmd->Parameters->Append($Cmd->CreateParameter('@Id', 3,
1, , $Id));
$Cmd->Parameters('@Id')->{Value} = $Id;
　　:

my $rs = $Cmd->Execute();

if (Win32::OLE->LastError() != 0) {
adoError(Win32::OLE->LastError());
}

# 戻り値を取得します
$retval = $Cmd->Parameters('@retval')->{Value};

ただ、通常のADOのように、PerlからでもResultSetにテーブル名を付けて、明示的にアクセスできるのかは、まだ分りませんでした....。

また、ストアドへのパラメータを指定する部分は、Win32::OLE::Variantを使えばもっといいのかもしれませんが、うまく動かなかったので、以下のサイトを参考に直接値を指定しました。

http://msdn.microsoft.com/library/ja/default.asp?url=/library/ja/jpdnvid/htm/VintrDev/VISQL/visql.asp

また、コーディングの際は、ActivePerlを使い、eclipse + Perl EPICというPerl用のプラグインを使ってみました。これもなかなか便利でした。(Visual Perlっていうのもあるんですね)

FOR XML PATHモード。

あきこ — Tue, 13 Nov 2007 16:57:00 GMT

覚え書きのようなものですが....。

SQL Server 2005では、FOR　XMLの機能が、かなり良くなっていました。（私個人的には、『とっても』でした）

SQL Server 2000の時と同じ、FOR XML Auto　とか RAWモードももちろん使えます。
ただし、上記のモードだと、お手軽ではあるんですが、Viewや一時テーブル、テーブル変数を使ったSELECTが、思いもよらないXMLで出力されることがありました。

でも、2005だと、PATHモードのおかげで、かなり自分の希望に近い形で、XMLを出力させることができるようになりました。

[今までのパターン]

SELECT Id AS Id, Name AS Name, ISNULL(NickName, Name) AS NickName
FROM [Test].[DocumentType] AS "DocumentType"
WHERE IsEnabled = 1
FOR XML Auto, Elements

-- 実行結果

<DocumentType>
<Id>1</Id>
<Name>見積り</Name>
<NickName>みつもり</NickName>
</DocumentType>
<DocumentType>
<Id>3</Id>
<Name>交通費精算</Name>
<NickName>こうつうひ</NickName>
</DocumentType>

上記は、FOR　XML Autoモードの場合ですが、SELECT結果が複数あった場合は、1行につき1つのXMLで、複数のXMLが返ります。(e4x的に言うと、XMLListという感じでした。)

この場合、私が直面した困った点は、以下の通りです。

ドキュメントルートのタグ（たとえば<root>...</root>）タグは自分でつけないといけませんでした。
また、要素と属性を混在したXMLにするには、EXPLICITモードとかを使わないといけなかったのですが、これが非常にわかりづらいものでした。
Viewを連結させた場合は、予想外の入れ子構造になっていたりしました。

なんとかあれこれ操作して、解決はできていたのですが、制限があって断念していたことも、いくつかありました。

[PATHモード利用]

さて、2005のドキュメントを見ると、PATHモードというものがあるのに、遅ればせながら気が付きました。

PATHモードを利用すると、わりと理解しやすいSQLで、XMLの出力をコントロールできるようになります。
EXPLICITモードというのが2000から使えたので、試してみたのですが、上記の通り、これが超理解に苦しみました。PATHモードを知った時、先にこっちを知っていれば...と、すくなからず後悔しました。

さて、SQLはこんな感じに指定しました。AS -> 要素名、@ -> 属性名になり、データは要素/属性のテキストノードとして格納されます。

SELECT (SELECT [Id] AS "@Id",
      [Name] AS "@Name"
      ISNULL([NickName], [Name]) AS "@NickName"
     FROM [Test].[DocumentType]
      WHERE IsEnabled = 1
     FOR XML PATH('Item'), TYPE) AS "DocumentType"
     FOR XML PATH(''), ROOT('root') -- root要素を追加

-- 実行結果

<root>
<DocumentType>
<Item Id="1" Name="見積り" NickName="みつもり" />
<Item Id="3" Name="交通費精算" NickName="こうつうひ" />
　　　　　　　　　　　：

今度は、root要素も指定できるし、要素と属性を混在させたりできます。

※ Namespace付きにする場合は、こんな感じで指定できました。

WITH XMLNAMESPACES (
   'http://blogs.passj.org/akiko' as Akiko)
　SELECT (SELECT [Id] AS "@Id"
      ,[Name] AS "@Name"
      ,ISNULL([NickName], [Name]) AS "@NickName"
FROM [Test].[DocumentType]
WHERE IsEnabled = 1
FOR XML PATH('Akiko:Item'), TYPE) AS "Akiko:DocumentType"
FOR XML PATH(''), ROOT('Akiko:root')

※WITH XMLNAMESPACES (....)がポイント。

結果はこんな感じになります。

<Akiko:root xmlns:Charon="http://blogs.passj.org/akiko">
<Akiko:DocumentType>
<Akiko:Item xmlns:Akiko="http://blogs.passj.org/akiko" Id="1" Name="見積り" NickName="みつもり" />
　　　　　:

</Akiko:DocumentType>
</Akiko:root>

もしかして、使い方を間違っていたり、まだまだ分っていないことがたくさんありそうですが、私には嬉しい機能でした。

そんなことを書いているうちに、もう2008....。いったいどうなるのでしょうか、楽しみです。

いまごろですが、CTE。

あきこ — Fri, 24 Aug 2007 16:51:00 GMT

部署の情報を格納したテーブルを作っています。

ここには、ParentIdという列に、1つ上の親の部署Idを格納しています。ここから、上下の関係を導出する...という具合に考えているのですが、この方法だと、どうしても再帰クエリになってしまいます。

Oracleでは、CONNECTというのを使うとうまくできそうなんですが、SQL Serverだとどうしていいのか分かりません...。

（階層は深くても4階層くらいまでなので、固定のSQLでも頑張ればいいのですが）

また、データはDBはRDBにフラットに定義しておいて、実際にアプリケーションに渡す場合は、XMLに加工して使おうと思っています。

色々探していたら、CTEというのが使えるんですね。

正しい方法じゃないかもしれませんが、とりあえず、やってみると....。

USE Common

GO
WITH Recursive (ParentId, Id, Code, Name, Level)
AS
(
-- Divisionの定義
    SELECT D.ParentId, D.Id, D.Code, D.Name, 
        0 AS Level
    FROM Division AS D
    WHERE ParentId IS NULL
	AND IsEnabled = 1
    UNION ALL
-- 再帰の定義
    SELECT D.ParentId, D.Id, D.Code, D.Name, 
        Level + 1
    FROM Division AS D
    INNER JOIN Recursive AS R
        ON D.ParentId = R.Id
	AND IsEnabled = 1
)
-- 再帰テーブルから取り出し
SELECT ParentId, Id, Code, Name, Level, replicate('-', (Level)* 10) + Code 
FROM Recursive

結果。個人的に、かなり感動しました(^^;

FOR XML, PATHモードを使えば、そこそこ希望しているものが作れるかもしれません...。

硬直の瞬間。

あきこ — Sun, 18 Feb 2007 15:21:00 GMT

またしてもずいぶん間が開いてしまいました...。
相変わらず、仕事も育児も家事も、全部中途半端で、あくせくと過ごしております...。?

さて、昨年の最後の書き込みで、『年内に受験しないと～』と表明したにもかかわらず、その後の進展も報告も放置してしまいました。（皆さまからも励ましのお言葉をいただいたにもかかわらず、申し訳ありません....）

11月に入ってから、さらに忙しさを理由にしてしまい、実際に受験の時間が取れたのは、師走のクリスマス前でした。今回受験したのは試験番号：70-431(データベースの保守と実装）。しかも、受験申し込みは、受験日の3日前という、自分でも情け無いスケジュールでした。

日々SQL Serverでのお仕事をしつつも、実際に受験本を読むと、判らないことだらけ...。しかも使ったことのない機能ばかり。通勤時間になんとか赤本をめくるくらいしかできず、当日になってしまいました。

そして当日。通勤途上の試験会場での受験となりました。

メモ書き用のホワイトボードに、自身の無い問題の番号を書き写して、なんとか問題を進めていき、最後までたどり着きました。でも、とっても怪しいと思った問題の数は20問近く(^^;これでは絶対に受かりません...。

再度見直しを進めたのですが、それでもまだ怪しい。『これ以上見直しても、もう無理だ～』と思ったところで、終了のボタンをクリックしました。

ボタンをクリックすると、その場で採点され、結果が出ます。この判定までの、ほんの少しの間が、非常に精神衛生上宜しくない時間でした。（運転免許の試験の時に、電光掲示板に自分の番号がめぐって来るかどうかを待っていた時と同じくらい、ドキドキしていました）

その結果。ここで書くのも非常にお恥ずかしいのですが、ボーダーライン.....。700点丁度という結果でした(^^;;;後学のために、もう一回どんな問題が出たのか見直したいくらい、迷うものが多くて自分でもホトホト困りました。そして、帰ってから、参考書を読み直したのは言うまでもありません...。

＃こんな状態なので、他のネットで『満点で合格』とか高得点で合格しましたという書き込みを見ると、本当に済みませんという気持ちです。

個人的には、レプリケート、リンクサーバなどの設定を、自分の環境に取り入れることが出来たので、『勉強したこと自体は、やっぱり良かった』のに相違ございませんが。

そうこう言っている間に、VistaやらSQL Server 2005のR2 やらが出てくるんですね。なんとかがんばろう...。

最後に、コメントや励ましのお言葉を下さった皆様、ありがとうございました!こんな結果で恐縮なのですが、まずはご報告とさせていただきます。

SQL Server + IISでSOAP & Flex

あきこ — Fri, 15 Jul 2005 16:08:00 GMT

Flexについてコメントをいただいたりしましたので、私がどんな風に使っているのかということだけ、少しお話させていただきます。

Webのインタフェースを作る際、どうしても「クロスブラウザ」なものを用意しないといけませんでした。操作性を考えるとJavaScriptやDHTMLを使うと良いのですが、ユーザの皆さんが使っているのが、IEだけでなく、OperaやMozilla、FireFoxが混在している環境だったので、それを思うととても頭の痛い状況に...。

それなら、ということで、Flashの技術を使おうということになったのです。Flashと、データソースとのやりとりは、SOAPを使っています。

さて、SQL Serverがどう関わったのかと言いますと、このSOAPの部分です。

そもそもSQL Serverや.NETの開発環境自体、触れたのが昨年冬ぐらいだったので、まだまだVisual Studioの使い方や、WEBアプリケーションの作り方も良くわからない時期でした。かろうじて判るのは、SQLと、Javaに近い（と感じられた）C#。

その後、どうやって書けば良いかなあ、と思っているときに、PASSJアフタースクールのご縁で、藤代さんからWebMatrixのことを教えていただき、なんちゃってASPなものを作ることができました。少しは.NETな環境に慣れていったので、希望の光は見えつつも、やはりコーディングに四苦八苦する日々。

上司も実は.NETな環境は初めてで、共に判るのはSQLだけでした。「なんとか楽をできないかなあ」と、上司と話していた時に、SQL Serverに加えて、IISとSOAP ToolKitを使えば、Stored ProcedureをSOAPとして利用できることを耳にしました。

早速やってみると、なるほど、とても作りやすい！

おかげさまで、「C#で書かなくちゃ。トホホ....。」と思っていた部分を、ほとんどStored Procedure内で処理できてしまい、かなり速いペースで目的のものを作ることができました。また、Flashで表示させるのには向いていない、表データを一覧で見せたり、CSVで提供するようなものは、同じくSOAP ToolKitを使い、templateを応用したりして、こちらも大変助かりました。

Stored ProcedureやSOAP Toolkitなどの情報は、やはり、PASSJのMLや掲示板などに大変お世話になりました。ですから、とても足を向けては眠れません。

SQL Server 2005ではどうやって作ればいいのか、まだ良くわかっていないのですけれど、うまく移行できたらなあと思っています。