異端な開発者を許ぃたってチョ☆

VS2010 Beta2 が出たので、Beta1をアンインストールしようとしたら、こんなメッセージが……

ファイル TFSObjectModel-x86_JPN.exe を探しています。
このファイルの場所を指定するか、Microsoft Visual Studio Team System 2010 Team
Suite Beta 1 - JPN ディスク 1 を挿入してください。

って、パス欄には、Users\ユーザー名\Local\Temp\20506.01.11\1041\ が示されているが、見つからないようだ。Tempってのが気になる。というか、消されてまったのだろうなぁ。

「こんなんでは、アンインストールできんがや」って困って、調べてみると、ハンスルマンさんのブログに解決方法が載っていました。

コネクトやフォーラムを調べてみると、どうやら、Beta 1 のバグのようで、Beta 2 では直っているようです。

個人的には滅多に使わないSelect句の中のサブクエリ。SQL Server Compact では使えないことが判明。

そんなはずは……と思うと、Books On Line に答えが。

SQL Server 2008 の解説

expression……定数、関数、または列名、定数、関数を演算子で組み合わせたもの、あるいはサブクエリを指定します。

SQL Server Compact 3.5 の解説

expression……列名、定数、関数、または演算子を使用した列名、定数、関数の組み合わせ。

確かに、「サブクエリ」という単語が消えている。もっと目立つように書いてほしいなぁ……

妻とやっとる、もう一つのブログで、妻とアカペラを多重録音したバッハの賛美歌をアップしました♪

http://blog.goo.ne.jp/sharondaniel/e/b44ce82d6d51c9aa6828d29fdbb2f7c7

文字連結は当然知っていましたが、Ｒ・田中一郎さんの「こいつ動くぞ」の記事で、

1 + "a" + true

が、"1aTrue"と評価されるのには驚きました。

さっそく、MSDNライブラリの「+ 演算子 (C# リファレンス)」を確認すると以下のように書かれていました。

数値型の場合、+ は 2 つのオペランドの合計を計算します。オペランドの片方または両方が文字列型の場合は、オペランドの文字列表現が連結されます。

なるほど。まず、最初の + が出てきたときに、片方が文字列と認識され、"1a" + true となり、これも片方が文字列なので、"1aTrue"となるわけか。

だから、1 + 2 + "a" は、まず、1 + 2 が評価されて、3 + "a" となり、"3a"となる。

"a" + 1 + 2 の場合は、まず、"a" + 1 が評価されて、"a1" + 2 となり、"a12"となるわけですね。

しかし、「MSDNライブラリの説明は、あの短い簡潔な言葉で、ここまでの説明をしているとは、素晴らしい！」と変な感動をしてしまいました。

IronPython が Python 3.0系に対応するのはいつだろうと、ずっと気になっていたが、次期.NET 4.0の後で対応されるそうだ。

InfoQの記事

IronPythonは、文字列の扱いがユニコードなので、Python3.0系っぽいと思っていたので、ちょうど足並みが揃って嬉しい。

ライブラリの互換性の面でも、完全コンパチではないので、どうせなら早く3.0系に合わせてほしいと願っていたのだ。

VS2010と同時に出るのは、それのプレビュー版で、3か月ほど遅れてリリースされるらしいが、待ち遠しいものである。

Vista は人気イマイチだったけれど、陰で応援してた。だって、MSさんから授かった我らが.NET の財源は Windows だから。

この不景気の中で、新しいＯＳ Windows 7 は、旧製品リプレイスとなるか？

Windows XP がそれまでのOSよりずっと優秀だったので、ずいぶん長生き。この優秀君に勝たなければ、MSさんにも我らが.NETにも未来はない。

差別化として、マルチタッチはどうだろう。ワコムさんが頑張ったらしい。

http://journal.mycom.co.jp/news/2009/09/16/101/index.html

競争に勝ってほしい。Vistaの弟、7に。

……ってそういえば、マルチタッチって、特許Appleがとってなかったっけ？

Windows Vista から Windows 7 にアップグレードしたら、それまでのWindows メールがなくなっている。アップグレード時に、「なくなるヨ」と警告してくれていたので知ってはいたが、ちょっと悲しかった。Windows Live Mail をダウンロードして、実行しようとしたら、

このファイルのデジタル署名を確認できませんでした。

云々というメッセージが出てインストールできない。ほかにも、色々設定をいじろうとすると、同じエラーが出る。ふと考えると、UAC の場面で出ていることに気付いた。

実は、Norton UAC Tool というのが、Vista の UAC の煩わしさを軽減するというので、入れていたのだ。UAC をOFFにするのは、機能を捨てているようでもったいない気がするのと、何よりも右下に赤い盾マークが出るのが嫌だったので、ずっとUAC ONにしていたのだ。そこに、Norton UAC Tool を入れていたわけだ。

↓以下は、窓の杜による Norton UAC Tool の説明
VistaのUAC機能を丸ごと置き換えてイライラを解消できる「Norton UAC Tool」

インターネットがあって、というか、人柱って大事だと思った。↓以下の記事のコメントで助けられた。記事のコメントのおかげで、クリーンインストールしなくて済んだ。
Norton UACを入れたままWindows 7にアップグレードしてはいけない

このブログは、同じような症状で困っている人のため、ログを記している。ずっと書きたかったけれど、更新できていなかったけれどね。

個人的な想いを、別ブログに書いてみました。

http://blog.goo.ne.jp/sharondaniel/e/fcc3ee5ed35f619401c3fcbcf9271f35

ローカルデータベースキャッシュとしても利用できるSQL Server Compact(以下、Ce)。これがなかなか使いづらい。

xmlなどデータ型が対応していなかったり、SQL文は、一文づつしか発行できなかったり、ユーザー定義関数もストアドプロシージャーもない。

sysobjectsなどのシステムテーブルもない。

ローカルデータベースキャッシュでは、アソシエーションまでレプリケートされない。

泥沼にはまったのは、Entity Framework だ。

from i in cx.HogeEntitySet where i.Name==stringFuga select i; で、エラー。が出て、そのエラーが「ntext型とかimageとかはクエリできないよ」的なエラーで、これには参った。

これは、バグらしく、以下のページを見つけて、何とか切り抜けた。

http://social.msdn.microsoft.com/Forums/en-US/sqlce/thread/b6bac277-cf66-4c74-a0b3-e48abedbd161/

これは、こう書けば解決。 cx.HogeEntitySet.Where(string.Format("it.[Name] == '{0}'", stringFuga)

データベースは、SQL Server しかよく知らないので、他の製品はどうかわからないけれど、Bitってつかいにくいな、と今まで思っていた。

Management Studio でも、編集画面だと、True、False で現われ、0とか1とか入力すると怒られ、True、Falseで編集しなければならないのに、他の場面では 0,1 で扱わねばならない。

Convert や Cast を使わずに、どれほど正確に Bit として認識してくれるのか、実験してみた。

ストアドプロシージャーの引数に、Bit を設定してみる。こんな風に。

で、引数の @a に色々と渡してみる実験。

当然のことながら、0、1は突破。'0'、'1'でも、問題なし。これくらいは当たり前。しかし、ここからがなかなか賢くて「おおっ」と思わせてくれた。

0以外の数字なら、すべて 1になる。''で囲っても同じだ。大文字と小文字を混在しても、'FaLsE'とか'tRUe'とか、それぞれ0、1と扱ってくれる。

これはやってて知ったのだが、SQL SERVER にも、TRUE、FALSEという予約語のようなものがあるらしく、''で囲わずに、TRUE、FALSEでも認識してくれる。

そして、空文字列の場合……　0にしてくれる。これはかなり、ありがたい。NULLのときは、NULL。これは当たり前。

つまり、かなり柔軟に受け止めてくれるということだ。'TRUE'、'FALSE'以外の文字列（上記のように、大文字小文字は区別しない）だと、エラーとなる。

たぶん、無理だと思ってやったら、やっぱしだめだったのは、全角の数字。エラーになりました……

Linq to Entities で、したいことの一つに、ある値を複数指定して、それに合致するものを取り出したい、ということがあった。 たとえば、１、３、５のIDのものを取り出したいとき。

けれども、Linq to Entities では、NotSupportedException が出る。「Containsは、いかん」というのだ。 おかしいな、そんなはずは……と思いながら調べていたら、ＭＳＤＮに、今回のリリースではサポートされないとの記事が……

ちなみに、Linq to SQL では大丈夫だったので、その部分は、Linq to SQL を使った。

最近、Entity Data Modelを扱っている。

edmxファイルを開こうとしたときに、エラーが出て、それ以降二度と開けなくなることがある。

「操作を完了できませんでした。パラメータが間違っています。」　……これで、二度泣かされた。

しかし、今回ばかりは本当に苦労して作ったモデルだったので、何とかして復旧させようと、edmxのXMLを解析し、やっとのことで、エラーの原因がわかった。

デザイナ周りの自動生成XMLが、唯一でないといけないはずなのに、同じコードを二度、生成してしまっている箇所があるではないか。その生成コードの一方を削除すると……edmxデザイナが無事に開いた。

つまり、原因は、edmxファイルの終りの方、デザイナセクションの<edmx:Diagrams>要素の中の<Diagram>要素の子要素の宣言の重複にある。私の場合は、<Diagram>の中の割と前の方に宣言されているAssociationConnectorと全く同じものが、</Diagram>で閉じられている直前にあった。

これは、Beta2の頃から、英語版のConnectにもレポートされているバグだが、未だ治っていないようである。

最近、WCFを実装しています。よくよく考えれば当たり前のことなのですが、サンプルを見て、わかった気になって調子こいて、結構痛い目に遭ってマス。

つながったり、つながらなかったり……　この不安定さはなぜ？　……やはり原因は、いつも設定項目です。あの、App.configとかWeb.configとかです。

単純によくよく考えれば当たり前のことなのですが、タイムアウトやデータ量の制限など、サンプルに使われているものはほとんど、小さなサイズのデータであって、タイムアウトとかデータ量制限とかには引っ掛かりませんし、設定も取り立ててしないと思います。

けれども、実際に実装してみると、デフォルト制限値が結構厳しく、すぐにエラーになってしまいます。

デフォルトで危険にさらさないように、という配慮なのでしょう。少しずつ経験を積んでいくしかないな、と思っております。

よこけんさんのページは、この制限についてうまくまとめられていると思います。

.NET Framework 3.5 SP1 をインストールしてから、インテリセンスの大半が英語表示（公には「一部英語」とありましたが、あれはどう考えても「ほんの一部日本語」でしょう）になっていたので、「はよリリースされんかなぁ」と思っとりましたが、やっとリリースされ、喜んでおります。

ディベロッパー製品開発統括部 Blog

やっぱし、日本語のほうがいいなぁ。落ち着くというか、効率が違います。「別に英語でも日本語でも大差ないよ」と言うようになれたらいいですケドね。

MSDNを見ると、ADO.NETのマッピングは、XMLと書かれているのに、SqlCommand.ExecuteScalar メソッドで実際に取得してみると、内部String型のObject型……

なぜだらう？　ん？ と、いうか、.NET FrameworkのXML型って?? XmlElementとかXElementとかしかないんじゃ。

そういえば、完全なXMLではない、要素とか、値のコレクションみたいなものもあるから、Stringでないと困るだろうなぁ。

でも、たしかLINQtoSQLでは、XElementになるはずではなかったかなぁ。う～ん……

VS2008から、ADO.NET Synchronization Framework などの興味深いものが出てきていたのですが、VS2008のSP1Beta を入れた頃から、SQL Server Compact 関連の機能を使おうとすると、

「指定されたプロバイダ 'Microsoft.SqlSercerCe.Client.3.5' は存在しません。」

などと、悲しい表示が出て、その機能が全く使えないでいました。たとえば、.sdfファイルを作るときにも、アウトでした。

SP1のRTMを待ちに待って、やっとインストールしたのに、全然解決しなくて悩んでいたのですが、やっと解決しました。

 http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=3466631&SiteID=17  の一番下の方法、

「VS2008SP1ディスクイメージの中のSSCEVSTools-JPN.msi」（リンク先では、JPNではなくて、ENUですが）を単独でインストールすることです。

普通に、Visual Studio、SQL Server、.Net Framework、Synchronization Framework などを再インストールしてもダメでしたし、

%WinDir%\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config を編集してもダメでしたが、この方法でいとも簡単に解決して、ようやくスッキリしました。

.NET Framework 3.5 になってから、色々な便利機能や名前空間が増えた。その中でも、お気に入りは、System.Xml.Linq 名前空間だ。XMLを扱うのに、非常に簡素で素敵な機能を提供してくれている。

まず、Document を考えなくても、Element 単位で考えられるところがよい。XElement は、たとえば、以下のように生成できる。

ここでの x の中身は次のようになる。

<要素 属性="値">
  <子要素>
    <孫要素 />
  </子要素>
</要素>

つまり、階層構造を真似て記述でき、引数を複数指定できるので、ありのままの XML を記述できる。また、Namespace を制御する XNamespace もシンプルで冴えている。string と同じような扱いをするように設計されており、コンストラクタがない。使い方は、

と、こんな感じ。XElement などに指定する時も、string にならって、

と、こんな書き方である。しかし、n は string ではなく、あくまでも XNamespace。x2.Name は、string 型ではなく、名前空間とノード名が一つになった XName 型である。要素名を取り出すときは、x2.Name.LocalName となる。

System.Xml 名前空間は W3C に準拠して設計されたと思われるが、System.Xml.Linq 名前空間は、最適化された全く別の設計思想(つまりはLINQ)に基づいていると思う。

DataGridView の DataSource に DataTable を指定しても、そのままでは列がデータバインドしてくれない。いわゆる「非バインド列」とみなされてしまうからだ。データ連動させるためには、列をバインドさせてあげなくてはならない。、

• DataGridViewColumn.DataProperty に DataColumn.Name の値を設定
• DataGridView.DataSource に DataTable を設定

基本的に、この２点で、列同士がデータバインドされる。順番は、どちらからでもOK。でも、DataSource を指定した後に、DataColumn を追加すると、DataGridView に列が勝手に作られてしまうため、それを抑止するに、DataGridView.AutoGenerateColumns を false に設定する必要がある。

SQL Server のデフォルトでは、既定のデータベースは、master になっている。しかし、Management Studio など、いちいちデータベースを切り替えるのは、面倒なので、既定のデータベースをよく使うデータベースに設定していた。

よく使うデータベースをよそに移そうと、デタッチしたら、Management Studio からつなげられらくなってしまったではないか。本当に焦った……　ログイン全部をそのデータベースにしていたからだ。

SQLCMD で、master を指定してログインしたら、ログインできた。sp_attach_db で、アタッチ成功。あーよかった。

せめて管理ログインは、既定のデータベースをmaster にとておくべきと、つくづく思った今日この頃でした。

SQL Server 2008 から、Native XML WEB Services 機能が、Deprecated になりました。

日本語 MSDN Library なのに、そこだけ英語なので、流行っとらんかったんかな、と思いましたが、やはり、WEB Service 関連は、ASP.NET に譲るべきということなのでしょうか。それとも、もう SOAP はやめていこう、ということなのでしょうか。

最近、.NET Framework 3.5 からの WCF のREST 対応を見ても、今までの SOAP 形式から、軽量の REST へ時代は動いとるんかな、と思います。

MSDN Library には、そんなにSOAP に対応させたいと言うなら、 WCF か ASP.NET を使え、と書いてあります。たぶん、今度 .NET Framework 3.5 SP1 で提供される ADO.NET Data Services では、もっと簡単に、宣言的に実装できるのでしょう。

個人的には、「SQL Server 自身が、WCF のエンドポイントを持ってくれたらなぁ」と強く思います。