T-SQL の TRY-CATCH

T-SQL にも TRY-CATCH があるわけです。
だからと言って、なんでも捕まえてくれるわけではないので、注意が必要です。
ハマリがちなのがこのパターン、

[T-SQL]
BEGIN TRY
 DELETE SomeTable
END TRY
BEGIN CATCH
 –テーブルが無いので、あれやこれや…
END CATCH

で、これは捕まえてくれないんです。
これは「名前の遅延解決」を行おうとして発生したエラーなので、CATCHしてくれないのです。なので、きちんとテーブルの存在確認をしてあげる必要があるわけです(see:「テーブルの存在確認」)。
同じように、単純なコンパイルエラーも捕まえてくれません(←当たり前と言えば当たり前)。
ま、この辺りのことは、TechNet – SQL Server 2005 Books Online – Transact-SQL での TRY…CATCH の使用
に詳しいので、そちらをご覧ください。

Sandcastle で作ったヘルプにサンプルコードを載せる方法

Visual Studio 2005 でサポートされるXMLコメントに、<code>と<c>があります。どちらも、サンプルコードを書くときに使うものです。
(<code>が複数行、<c>は一行です。)
この辺りのXMLコメントについては、MSDN-Visual Basic 言語リファレンス-ドキュメントコメントとして推奨されるXMLタグ(Visual Basic)をご覧ください。
で、これで作った結果をSandcastleでビルドしてやると、サンプルソースとしてきちんと…表示されないのです。あろうことか、VB.NETで書いたはずなのに、C#の言語タグで表示されてしまいます。これは困ります。
これを避けるためには、<code>タグにちょいと手を入れてあげればよいのです。
<code lang=”VB”>
としてあげれば、きちんとVBのコードと認識されて、しかるべき色付けまでしてくれます。
VBでもVB.NETでもVBNETでも、さらに大文字小文字も関係なく、どれでもOKだそうです。
詳しくは、”Sandcastle Help File Builder”付属のHelpから、”The Code Block Component”の項目へどうぞ。
他にもタイトルや、ソースファイルの指定、さらにその中のRegionの指定まで出来るようです。

SQL Server 照合順序の意味

“Japanese_CI_AS” とか。
意味もわからず呪文のように覚えていた頃もありましたが、意味がわかれば結構簡単に覚えられます。
先ずはこの”CI””AS”の末尾の一文字
“I”-Insensitive:識別しない
“S”-Sensitive:識別する
さらに、前の一文字
“C”-Case:大文字小文字(例:”A”と”a”)
“A”-Accesnt:アクセント記号(例:”a”と”á”)
“K”-Kana:ひらがなとカタカナ(例:”あ”と”ア”)
“W”-Width(?):文字列幅(例:”ア”と”ア”)
これらの組み合わせで出来ています。
なので、”Japanese_CI_AS”なら、「日本語・大文字小文字は識別しない・アクセントは識別する」という意味になります。省略されたものは「識別しない」になるようです。
「日本語にアクセント記号は無いぞ!」という至極最もな突っ込みはありますが、ちょいと実験してみました。

[T-SQL]
declare @Sometable table (
    SomeValue nvarchar(10)
    COLLATE JAPANESE_CI_AS )
insert into @Sometable values (‘か’)
insert into @Sometable values (‘が’)
insert into @Sometable values (‘カ’)
insert into @Sometable values (‘ガ’)
insert into @Sometable values (‘カ’)
insert into @Sometable values (‘ガ’)
insert into @Sometable values (‘つ’)
insert into @Sometable values (‘っ’)
select count(*), Somevalue from @SomeTable
group by SomeValue

【結果】
CNT     Somevalue
———– ———-
3      か
3      ガ
1      っ
1      つ
では、照合順序を”Japanese_CI_AI”にしてみると…
【結果】
CNT     Somevalue
———– ———-
6      か
2      つ
なんと、濁点はともかく、「小さい”つ”」も「アクセント記号」だったのです。(これは知らなかった…)
そして、これらのほかに
“_BIN”-Binary
“_BIN2″-Binary – Unicode codepoint
というのもあります。
このあたりについては、コチラ:MSDN-SQL Server Books Online- Windows 照合順序並べ替えスタイルに詳しく解説されています。

Sandcastle でシアワセに

ドキュメント生成ツールは世の中イロイロあります。
昔は、それ専用の独自タグを入れる必要があったりして、かなりイラつくものがありました。
で、製品を出荷した後でも、ン週間かけて関数仕様書やクラス仕様書を直すという、非常に後ろ向きな作業をやっていたわけです。
さて、そんな中、sandcastleを触ってみました。
そのやりかたは、コチラ:翔ソフトウェア (Sho’s) Fujiwo の日記-Sandcastle – September 2007 Community Technology Preview (CTP)に詳しく説明されています。
ただし、カレントバージョンはOctober 2007 Community Technology Preview (CTP)です。ダウンロードはコチラから。
で、同じようにSandcastle Help File Builderを使います。こちらのバージョンは1.6.0.1。ダウンロードはコチラです。
このOctober CTP + Help File Builder 1.6.0.1 ですと、Sandcastle Help File Builder を使用する必要はなくなっています。起動すると、ご丁寧に「やらなくてもいいよ」とメッセージを返してくれます。
さらに、Help Compiler を用意します。
1.x か 2.0 かを用意するのですが、2.0は Visual Studio 2003 Help Integration Kit の一部だそうなので、Visual Studio 2003 が入っていないとインストールできません(させてもらえませんでした)。
1.x は HTML Help Workshop and Documentation の一部で、コチラからダウンロードできます。
2.0 はコチラからダウンロードできます。
で、用意ができた所でやってみました(もちろん、XMLドキュメント出力チェックをつけてビルドした上で…)。
Help File Builder のおかげで、GUI操作でわかりやすいです。
で、出力結果。
デザイナ出力ソースなどはコメントがつかないので、警告を山ほど出力してくれます。
そして、待つことしばらく。出来上がったファイルを見ると…
ただコメントにポコポコ入力しただけとは思えないほど、ちゃんと出力されています。
…しかも手を抜いて書かなかった所まで丸判り…
これで、あの退屈な「仕様書直し」も軽減されそうです。
しかも、ヘッダコメントを書いてくれない人にも、書かせる動機付けの一部として使えそうな感じですね。
とりあえずご紹介まで。
————2007/12/04 追記————
タイトルに誤字がありましたので、修正しました。

Online Only?!

某所で「MSDN Libralyのドキュメント、Onlineだけでいいんじゃね?」という議論がありまして。
で、「冗談じゃない、Offline要るよ!」と反応しておいたわけですが、イロイロと挙がっていたその理由。
・社内で許可してもらうのが大変なんだよ!
(金融系とか政府系とか…そういうお堅い所だと昨今はそうですね)
・どこかに移動中のときどうすんだよ!
(出張中とか…余計な金を払ってネット接続することに)
・そんなに帯域幅ねぇよ!
(悪かったな、田舎住まいで!)
コードを書いていると、頻繁に[F1]のお世話になるわけですが、たいていはローカルコピーを見に行くわけです。これのいいところは、Localなので反応が非常に素早いこと-思考の流れを妨げないことなんですね、私が思うに。
もしこれが、ネットワーク越しでえらく時間が掛かる羽目になったら(理由はともかく)、相当にイラツキ-どころか、「仕事にならん」でしょうね。
そんなわけで、わたしは「Offline」のドキュメントを支持するわけです。

Office2007形式ファイルの罠?

Office2007形式のファイル-docxとかxlsxとかpptxとか-をzipやlhaで固めて、メールに添付しました。
すると、アンチウィルスというかファイヤーウォールというか、そういう製品によっては、zipの中をスキャンしようとするわけです。
これはこれで正しい挙動ですね。
しかし、Office2007形式ファイルは実はZipであるので、「Zipの中にZip」ということになります。
で、上の話で、そういうモノは、Zipの中を掘り進んでいくので、とてつもないファイル数になります。
で、ファイル数オーバーフローで処理中断という、笑えないオチになることがあります。
気をつけてどうこうという問題ではないのですが、こういうこともありますということで。

IMEの切り替え

日本語入力システムの切り替えは、
[Shift]+[Ctrl]
で行うことが出来ます(デフォルト)。
変換が重くなった?!と思ったらMicrosoft IME から Microsoft Office IME 2007 に切り替わってやがった!というときは、ウッカリこれを押してしまったのが原因です。
あわてず騒がず、言語バーか、同じショートカットで戻しましょう。

Oracle の文字コード

Oracleでインポートできないと言われまして、見に行きました。
ORA-01401 が出まくってました。しかし、もともとexpで出力したデータなので、基本的にはありえないはずです。
調査を進めていくと、varchar2(20)のカラムに漢字を入れた時(なぜnvarchar2じゃないんだとツッコミつつ)、6文字で終わってしまいました。
で、それを手がかりに文字コードの問題であるとわかりました。
・Export側:AL16UTF16 (つまり、UTF16-一般的な漢字は2byte)
・Import側:AL32UTF8 (つまり、UTF8 -一般的な漢字は3byte)
Oracleは自動変換を試みてくれたわけなんですが、これが罠だったんですね。
Export側ではAL16UTF16のvarchar2(20)のフィールドに漢字10文字を保持していたんですが、こちらではAL32UTF8のフィールドに漢字10文字を入れようとして、Overflow。
そんなわけで、AL16UTF16でデータベースを作り直してimpを流してみると、つつがなく終了しました。
おまけ)
impの実行時に「文字コードが違うよ、どうすんの?」と、ちゃんと聞いていました。ちゃんと見ようよ…

今更なメイリオとPowerPointの仕様についてのメモ

・メイリオには斜体はない
あれっ?と思ったのですが、今更調べてみると山のように見つかる上に、ちゃんとKBにまで載ってやがる。
KBはコチラ
したがって、ウッカリとドキュメントで「斜体の部分は…」などとやると悲惨です。
・PowerPointのスライド部分では、取り消し線は使えない
人に言われて初めて気がついたのですが、少なくともPowerPoint2000からこういう仕様だったようです。
何に使うのは別として、いざ使おうと思った時にコレというのは、ちょっと慌てます。
頭の片隅にでも置いておいて損は無いでしょう。

[小ネタ]キーボードの言語切り替え

キーボードに複数言語を入力できるように設定してある場合、あるいは複数のIMEが入っている場合(例:Microsoft IME と Microsoft Office IME 2007)、それらの切り替えは、
[コントロールパネル]→[地域と言語のオプション]→[キーボードと言語]タブ→[キーボードの変更]ボタン
で行います(Vistaの場合)。
この中の[詳細なキー設定]タブで、ショートカットキーを変更できます。
日英を共存させたとき、デフォルトは確か「左Alt + Shift」になると思います。
暇つぶしに Wikipedia を「おまかせ表示(Alt + Shift + x )」で遊んでいるとついタイミングがずれて英語モードになってしまうことがありますが、この場合はあわてずに「左Alt + Shift」で戻しましょう。
或いは、こっちの設定を変えてしまうのもアリですね。