2009年3月13日金曜日

ExtJs-32 DataTierGenerator(設定について)

DB周りを
DAAB化するってことで入れたのだけど、
実際の設定がわからん。
ぐぐったら@ITでヒット。
やってみた。

EnterPriselibraryConfigurationを起動
(XMLクリエータ的な感じなのかな。。。)
でApplicationを追加して
Applicationツリー配下にDAABを追加して。
ConnectionStringを編集して(これはいままで使用していたやつを。。)

保存。

ここからが
かなりいけてない作業のだが
動かすことを最重要目的としているため、
出来上がったXMLファイルの内容を
一つ一つ丁寧に
webConfig.xml
に移植した。

このあたり、もとのConfig周り含めて仕様をぜんぜん理解してないな。
だからこんな泥臭いことをやってる。
よろしくない。

おいといて。
で、参照の追加で.NETタブのなかにいろんなApplicationBlockが
あるのでDAAB、DAABデザイナを登録しておく。
デザイナがひつようかどうかのきりわけはしてない。し、
これはとりあえず後日。

でDataTierGeneratorで作成されたストアドも登録して。。
実行。。

おー、動いた。

ツールのプロトタイプがかなり立ち上がり早くなります。
よかった。
ってことでDAAB系列についてはいろいろ掘り下げる必要ありだけど
いったん収束で。
Gird+編集用Dlgのパターン実装におけるCRUDは
これでおおむねOKラインとして終えます。
いままで旧バージョンでセコセコしてたのがかなーり便利に。
DataBaseクラスのおかげで自力実装部分もかなり減った(闇に葬られた)し。
メンテが楽で。

いつになるかわからないけど次はLoggingのAplicationBlockをやろう。。
よりいっそうツール作成意欲がわいた。

でも時間が本当にとれないなぁ。。

ExtJs-32 DataTierGenerator(文字コード)

結局ニューバージョンでstreamWriter.WriteLine部分でも
てこ入れしなけりゃいけない。
UTF-8ボム無しになるのはなんとかならんものか。。。と。
デフォルトコンストラクタだとBOMなしなので。。。
結局StreamWriterのコンストラクタを変更してUTF8指定してBOM付で
吐き出すように変更して使用させてもらった。
これでソースはOK。

2009年3月8日日曜日

ExtJs-31 DataTierGenerator(DBの照合順序)

で、いよいよ
DataTierGeneratorでじぇねレートしなおうそうと。。
するとだね。
---------------------------

---------------------------
equal to 操作の "Latin1_General_CI_AI" と "Japanese_CI_AS" 間での照合順序の競合を解決できません。
---------------------------
OK
---------------------------

なんて出るんです。。
なんのこっちゃと思い、Collationの確認するも、masterDBや自分の作ったDBも"Japanese_CI_AS"よ。
うーんと。。と、なるのですが、
テーブル情報を取得するSQL文の中で
INFORMATION_SCHEMA.TABLES

FN_LISTEXTENDEDPROPERTYで作成した拡張情報を
LEFT JOINしてる部分において(equal to)って言ってるからそう判断しただけですが
どうやらFN_LISTEXTENDEDPROPERTYのCollationがLatin1_General_CI_AIで作成されている?
ようで、
COLLATEでキャストしました。ら、うまくいった。

ちなみに確認用に抜粋してみてやったものはこちら。

select * from INFORMATION_SCHEMA.TABLES
LEFT JOIN ::FN_LISTEXTENDEDPROPERTY('ProgrammaticAlias', 'user', 'dbo', 'table', default, default, default) AS ExtendedProperty ON INFORMATION_SCHEMA.TABLES.TABLE_NAME = ExtendedProperty.objname COLLATE Japanese_CI_AS

「COLLATE Japanese_CI_AS」
これね。
ちなみに
ジェネレートする際のSQL文についても同様。に
「COLLATE Japanese_CI_AS」を。



#追記(ぱっと見わからなかったのでまよったため)
・ソリューション構成のSQLフォルダ内にある、
・テーブル情報を取得するSQLの末尾に
「△COLLATE△Japanese_CI_AS」を追記する。

ExtJs-30 DataTierGenerator(EnterpriseLiblary)

で、
そういやDataTierGeneratorってバージョンアップしとらんのじゃんろうか?
と具具って見たら。。。
してました。

2.1.1.スナップショット見たら。VB.net対応してらっしゃる。
自前でやろうかと思ってたところだったから。
というか、
2006年12月って。
俺のバージョンドンだけ古いんだ?
まぁ、もともと引っ張りだしてきた自宅の引き出しがふるかったからなぁ。

で、

EnterPriseLiblary仕様になっててこれまたグレイト。
早速、2008向けのEnterPriseLiblaryをインストール。
いよいよEeePCも本格装備になってきた。
http://www.microsoft.com/downloads/thankyou.aspx?familyId=90de37e0-7b42-4044-99be-f8ecfbbc5b65&displayLang=en

ExtJs-29 DataTierが古かった

いろいろあってDataTierGeneratorのバージョンをアップした。
のでそのいきさつを。


古いバージョンでやってたころ、下記のようなことが起きていた。
日本語テーブル名、フィールド名を使用しできるように
メンバを_で。
と、
自前のSQLAccessクラスに変更したものの、
これは以前のVSの環境で、2003時代だった。

で、生成されたものを2008環境(EeePCは2008)
ではコンパイルできず。
あれれ?
UTF-8だろうがよー。
何でだよー。
とおもい
テキストエディタでも確認。
確認?すると?おや。
BOMなしジャンよ。。
VS2008だとどうやらBOM付でないとこんぱいるしてくれないのか。。

ってことはDataTierGeneratorのStreamWriterに文字コード指定してやらねばいかん。

セコセコと作って
自前のDBアクセスクラスで。、、、

で、そんな面倒なことやってられるか。
やはりDAABでやるべきなんだ。
と。

2009年3月7日土曜日

ExtJs-28 DateField

formatぱらめーたに Y/m/d
で、
実データはDateTimeのToStringでもどすため、 Y/m/d G:h:s
となる。

ので反映されない。formatにY/m/d G:h:s
って書くと 2008/12/31 0:00:00となってしまうし、..
これを自力でフォーマットするのはあほくさい。
調べたら。
あった。
altFormatぱらめーた。
これにY/m/d G:h:sを指定してOK!!
よかったー。

2009年2月22日日曜日

気が付けば

このブログ、なんで立ち上げたんだっけ?
と思えば転職。

で、また転職。
いろいろあって立つ鳥あと濁しすぎなかんじですが
かなり厳しい状況で。
疲れたなぁ。いろいろ。

毎日毎日を追われるように過ぎ、
ExtJsも触れず、
WorkShopにも出れず。
もやもやがたまったのでPCデポで自分へのご褒美ってことで
キーボード買った。
もともとREALFORCEのキーボードほしかったんだけど
予算オーバーだし。
そのつぎってことでFILCOのマジェスタッチ。
シャコシャコ音はするものの、メカニカルなカチカチとは言わず。
うち心地も良いし。
良かったと。

でも、このPCの前に座るのも久しぶりだな。

最近はEeePCが頻繁ですし。
会社の仕事をする際に使用する程度。
その頻度も少ないし。

で、気が付けば入籍記念日。
もう七年目だ。
子供生まれて転職して家建てて子供生まれて転職して入院してまた転職して。。。
そろそろ息切れしそ。

node + ejs + Socket.io のサンプル

まずい。。 一年間、一回も更新してない!!! つまり、、 趣味の時間がほぼ皆無ということの現れです。 業務と子育てに追われた一年でしたね。。。。。 危なく年をこすところだった。あぶない。なぶあい。 話を変えて。 今月初旬に 社内でちょっとしたプレゼンをする事に...