以前にもラベルが使えなくなったことがあったのですが（Visual SourceSafeで特定のラベルが取得できない），今回はラベルにハイフンなど入っていません。しかしVisual SourceSafe エクスプローラから共有・分岐してもプロジェクトフォルダー1つだけしか共有されませんし，取得しても何も起こりません。しょうがないので，ラベルの詳細情報を表示してバージョン番号を確認し
ss.exe CP $/MyProject/trunk
ss.exe Share $/MyProject/trunk -R -E -V[バージョン番号]
で共有・分岐しました。
というか最終的には分岐してtrunkの横に1.0ブランチを作りたかったのですが，コマンドラインに「1.0」を入力する場所がなくて一体どうするんだオイと思っていたら，Shareコマンド実行後に「$/MyProject/trunk のコメント」と「新規プロジェクトの名前」の入力を求められました。なんでそこだけインタラクティブなんだ…。
撮影装置はだいたい海外製で漢字なんて知ったこっちゃないので，生成するDICOMデータには患者名の漢字とかフリガナは含まれません。でもそれだと使い勝手が悪いということでがっつり日本製のオーダリングシステムからもらった漢字とかフリガナをDICOMデータのほうに反映してやるわけです。
で，オーダリングシステムはたいていShift JISでデータを送ってくるのですが，使っていい文字についての規定などあるわけもなく，Windowsで表示できればどんな文字でもOKという状況です。これをDICOMデータ用にJIS変換するのにICUを使っているのですが（コンバータは"JIS8"），ICUはかならずUnicodeを経由するので（そしてShift JISからUnicodeへの変換はかならず成功するみたいなので），UnicodeからJISへの変換に失敗する文字が出てきます。
失敗といっても二通りありまして，ひとつは日本語でない文字集合のエスケープシーケンス（「1b 24 41（中国語）」か「1b 24 28 43（韓国語）」）が使われるケース，もうひとつは既定の文字集合で「0x1a」に変換するケースです。いずれの場合もICUはエラーを返さないので注意が必要です。
ちなみに以下の文字については（たぶん正式には基本漢字に含まれないのですが）がんばって変換してくれます。
PS 3.3 - 2011 の Table C.12-3 DEFINED TERMS FOR SINGLE-BYTE CHARACTER SETS WITH CODE EXTENSIONS によると，JIS X 0201: Katakana を使う際の ESC sequence は「ESC 02/09 04/09」となっています。これはつまり G1 working set に1バイトカタカナを指示（designate）しているわけで，DICOMでは8ビットモードを使ってねという話を考えるとなにもおかしくないのですが，ICU 4.8 でこのエスケープシーケンスから始まる半角カナをUnicodeに変換すると，エスケープシーケンスがまるっと残ってしまいます。8ビットモードなのでucnv_openに渡すconverter名は「JIS8」なのですが，どうもこいつは「カタカナをG1にってそんなんいちいち指示しなくても最初から割り当てられてますやん。そんな指示意味ないですやん」と判断しているご様子。ちょっといまソースコード読む気力がないので推測なんですが。
というわけで上述のエスケープシーケンスはICUに渡す前に「ESC 02/08 04/02」あたりに変換しておくとよいようです。
※日本語なんだから「ESC 02/08 04/10」でいいんじゃないのとも思ったのですがこれだとバックスラッシュが円記号（U+00A5）に変換されてしまってたぶんまずいことになります。
put_ValueでIDispatch error #3105 の続きです。今回はINSERT後に@@IDENTITY列の値がほしい→しかしテーブルにINSERTトリガが仕込んであるため動的プロパティ"Update Resync"を設定しなくてはいけない→adUseClientにしなくてはいけないということでサーバサイドカーソルで逃げられなかったので，トレースを仕込んでがんばってみました。ADOのバージョンはいつのまにか6.1.7601.17761です。
こんな感じで，途中までは調子よく進んでいるのですが，なぜかIsLegalDBtype()がDB_E_BADBINDINFOを返すため最終的にDB_E_ERRORSOCCURREDが返ってきてしまいます。お手上げです。
ちなみにトレースを仕込む際%SYSTEMROOT%\SYSTEM32\msdaDiag.dllと書くとなぜかうまくいかず，環境変数を使わないでC:\Windows\System32\msdadiag.dllと書くとOKでした。
C++/CLIで，ネイティブ関数→同じアセンブリ内のマネージド関数→参照アセンブリ内のマネージド関数という順で呼んでいたのですが。
#pragma managed(push,off)
void MyNativeFunction()
{
MyManagedFunction()
}
#pragma managed(pop)
void MyManagedFunction()
{
try
{
MyManagedDllClass::AFunction();
}
catch (System::Exception^ e)
{
ShowError(e);
}
}
MyManagedDllClassの格納されているアセンブリ（ここではMyManaged.dllとします）はプログラム起動時には読み込まれず，必要なときに動的に読み込まれるのですが，MyManaged.dllが存在しない状態でプログラムを起動しようとすると（まあつまりインストーラに組み込み忘れたってことですが）いきなりプログラムが落ちてしまっていました。try/catch書いてるのになんでだ！ とびっくりしたのですが，MyManaged.dllはMyManagedDllClass::AFunction()が呼ばれる直前ではなくMyManagedFunction()が呼ばれる直前に読み込まれるのですね。そこで
#pragma managed(push,off)
void MyNativeFunction()
{
MyManagedFunction()
}
#pragma managed(pop)
void MyManagedFunction()
{
try
{
MyManagedFunctionIntenal();
}
catch (System::Exception^ e)
{
ShowError(e);
}
}
void MyManagedFunctionIntenal()
{
MyManagedDllClass::AFunction();
}
としてやったところ，MyManaged.dllが存在しなければSystem.IO.FileNotFoundExceptionがちゃんとcatchされるようになりました。