Team Foundation Server 2010、テスト導入してみたよ！
以下の順番でインストール
1.SQL Server 2008R2 Standard(x64)
2.Sharepoint Server 2010 with sp1(x64)
3.Team Foundation Server 2010(x64)
4.Team Foundation Server 2010 sp1
これでTeam Foundation Serverマネージャーで構成開始
うまくダッシュボード上のグラフが表示されない・・・はて
Windows UpdateやったらOfficeのOWCコンポーネントがUpdateされて、表示OKに！
そういえばOWC11以降は無くなるような記事が出てたけど・・・
VSSにバイバイできるかなぁ
Jsonの項目内の改行コードの記述方法について
サーバーサイドでは\マークはエスケープ文字としてよく利用されている為に
ついつい”\n”の状態にてJsonに含めるとクライアントサイドのeval時にエラーとなる。
なのでエスケープされる場合は”\\n”と2回つけることを忘れべからず！
もちろん多数ある場合も改行コードを上記のように置換処理をすること！
PHPの場合はダブルクォート「”」とシングルクォート「’」でエスケープされる、
されないが変わるので、どちらかに統一するのが望ましい。
これはJsonだけの話ではないが、重要なので記述！
javascript側では受け取ったJsonを展開するときにカッコで囲ってあげること！
例：var a = eval(‘(‘+json+’)’); //このカッコ追加は結構注意！
覚書（＾ ＾）
毎日寒いね～・・・一気に冬将軍到来か！って感じですが皆さんいかがお過ごしでしょうか？
題名のとおりDotNetになってFormat関数があることにはあるのだが、挙動が違うので、少々覚書
VB6のまま使用するのであればMicrosoft.Visualbasic.Format関数というものが存在するのでこちらを使用する。
ただし「Microsoft.Visualbasic」を使用する時点で「.NET Framework」構想からは外れた設計になることを覚悟の上ですが・・・
まぁそうは言ってもAPIの使用やComをCreateObjectするのではないので「.NET Framework」が入っている環境であれば動くから良いかな:roll:
違いといえば、いろいろ違いますが中でも良く使う日付系の指定文字だけど「yyyy/MM/dd HH:mm:ss」とmmの大文字小文字をちゃんと指定してあげないと月なのか分なのかみたいな狙ったとおりに動かなかったりといろいろあるんだよね。
細かいところは調べてみてね！
なんかこのブログを見てくれている方が回りにいらっしゃるようでうれしい:roll:
突然ですが、言い訳言わせて！
・現在、IE7やFireFoxではCSS設定のサボりで描画が乱れます（苦笑）
・ページ最後のLatestPostとLatestCommentも同一の物が表示されているのもプラグイン導入のサボりです（汗）
そのうち直しますのでお許しを:cry:
さてさて本題♪
DataSetについてだけど、DotNetからクライアント側のViewとしてDatasetが使われるようになっていますが、
内部にはまさにDatabase丸ごと入るような設計になっているため、使いづらい場面が多々あったんだよね。
ようするにTableを複数保持したりDatasetからじゃないとシリアル化出来なかったりと「アクセスの入り口はDataset!」
と強制されていた。
しかし、ADO.NET2.0になってから（VS2005・・・VS2003もかな）はDataTableにも使いやすいメソッドが多数のって
DataReaderなどのと連携も簡単に取れるようになった、えらい！
DB情報の使いかただってTable単位のアクセスが多いし、複数のテーブルを一気に使用する頻度って少ないと思うんだよね。
そうするとDataTableだけを使用してI/Oした方がプログラマも分かりやすいしイメージしやすい！
つーことでDataTableに一票！:razz:（初めからこうしてよMSさん・・・・）
過激な題名から入りましたが、VB.NETのお話です。
さてVB6などから.NETになってDatabaseへのアクセスするのに以下のようなクラスを使うようになりました。
・DataReader
・DataAdapter
終わり・・・
かなりハショッてます（汗）
要するにConnectionとCommand系クラスはあまり変わらないのですが、
Recordsetだけは大きく２つのクラスに分解されています。
Selectデータの取得方法が前者に上げたDataReaderとDataAdapterになったのですが、
それぞれ使用する場面が分かれます。
１．DataReaderは前方向カーソルのデータ取得になっていて取得はグルグルLoop処理が必要になります。
「メリット」
View情報がDBサーバー上にあり、クライアントサイドにはReadしない限り保持されないので動作が軽い。
「デメリット」
データは上位順にしか取得出来ないのでApp側でコントロール表示などは行ってあげる必要がある。
Paging処理など動的にPageクラスにセットしてあげる必要があるので簡単に出来ない。
２．DataAdapterはDataSetクラスにヒットしたデータを一発でいれる
「メリット」
DataSetを使用して動作するコントロールが多数あるので開発が楽。
必要なデータを簡単にDataSetを通じてClose後でも使用できる。
Paging処理もクラス任せで楽。
また、直感的に修正して更新も出来るなど使い勝手が良い部分も
「デメリット」
ヒットしたDataを全部DataSetに入れるのでクライアント側のメモリ領域を使用してしまい処理が遅い。
(要するにグルグルLoopをALLしてるってこと)
以上になります。
一見すると「DataAdapterの方がいいところいっぱいじゃん！？」と思いでしょう？？？
ここが落とし穴なんだがや！
楽だと思ってDataAdapterでFillばっかり使っているとやられてしまうで（誰だお前は（苦笑））
もちろん使うタイミングの問題なのですが、Webでもクラサバでも主要なデータを任意のキーで
検索する機能があるシステムが多くなってきました。
この時にDataAdapterを使用して大量データの表示、Paging処理など行うとヒットしたデータを
DataSetに入れてしまう関係でとんでもなく遅い処理になってしまいます！
DataGridなどで大量データを扱う場合に表示が遅いのはこのためドス:oops:
★具体例だと、100万件のデータを任意で検索し10件ごとPagingし3Page目を表示する時、
仮に100万件がヒットしたとして、ヒットデータをDataSet(メモリ)に入れる、
そこから30件目見つけて10件分を表示することになっているので、なんで？って思えるぐらい遅いです。
DataReader使ってLoopで30件目から10件分、取ってきたほうがよっぽど早い！
管理人のテストでは最後の10件を表示する時もこちらのほうが数倍早かった:roll:
余談だけど、Paging処理はDBによりSQLに任せる方法もあります。
例えばMySQLやPostgresなどはLimit関数、SQLServerやOracleはRowIDを使用するなど
しかし、DBによってはPaging処理が整っていなかったりするのでApp側の違いを覚えておくのも
損はないでしょう♪
作成段階では少量のデータで問題なく動いても、普通はテスト段階、あるいは本番稼動後、
じわじわとボディーブローのように遅くなってきます。
昨今はWebはもちろん企業内のシステムも膨大な検索が出来るシステムになってきました。
作ってからの手直しはデグレが怖くて直せなくなりますので作る前からの情報をお勧めします。
最後に適材適所が必要で、DataSetも使う場面によっては楽チンである:???:
管理人も2003の時にテスト段階でこの問題に気づきPaging処理などを直したことがあるので復習兼ねて覚書:razz:
おまけ「DataSetの新機能」非同期って言葉がミソ♪
