なっちゃんのプログラミングTips

SQLServer2005Expressをインストールすると本体(SQLServer)と一緒にSQLServerBrowserがサービスに組み込まれるが、これまで全く使っていなかった。
既定でも無効になっているのでどういう使い道があるのか知らなかった。

たまたま仕事でAccessデータベースをSQLServerに移行させる必要があり、サーバ機を用意するほどの予算もないので既存のXPマシンにExpress版をインストールして使うことになったとき、ODBC経由でネットワーク接続しようとしてODBCデータソースが作成できなかったことから調べていって判ったことである。

通常SQLServerのTCPポートは1433番固定なのだが、Express版は動的ポートが採用されている(今回初めて知った)。
そこでリモートから接続しようとするときどのポートに接続したらいいのか調べる必要があるが、それを行ってくれるのがSQL Server Browserというのである。

またXP(sp2適用)ではファイヤーウォールが有効になっているため、外部からSQLServerサービスとSQLServerBrowserサービスに接続するには、必要なポートを開ける必要がある。
実のところこれまではデータベースサーバとしてWindowsServer2003を使っていた。2003ではファイヤーウォールは既定では無効になっていたので意識する必要がなかったのだ。

固定ポートを使用していればファイヤーウォールの設定はそのポート番号を許可させるだけでよいが動的ポートの場合にはそれができない。
そこでサービスプログラム本体(sqlserver.exe)を許可させたあと、SQLServerBrowserサービスを使ってインスタンス名からポート番号を探る必要がるので、こちらも許可させる必要がある。なお、こちらはUDPの1434番(固定)を指定するか、sqlbrowser.exeを指定する。

詳しいことは下のサイトに紹介されている。
http://www.atmarkit.co.jp/fdotnet/dotnettips/545sqlsvrnet/sqlsvrnet.html

なお、余談だが今回Access2000のデータベースをSQLServer2005Express版に移行するのにAccess2000のアップサイジングウィザードを使ったところ「オーバーフロー」のエラーが発生した。この原因を調べたところAccess2000のバグのようでOffice2000ServicePack3を当てることで正常に変換できた。

http://www.microsoft.com/windows/windows-7/beta-download.aspx
http://www.microsoft.com/japan/windows/windows-7/beta-download.mspx

上記でWindow7 Beta 日本語版がダウンロードできます。
どれどれ試してみようではないか。

インストールから終了までざっと紹介。
デザインはほぼVistaと同じである。
まだ英文のままのメッセージも多い。

５年前に作ったVB6のあるプログラムがデータ量の増大に伴い処理速度が落ちてきた。
データベースはMSDE2000(SQLServer2000相当)でADOを使っているが、適切な手続きをしていればそんなに遅くなるはずはないのに何故かと疑問に思っていた。

そのプログラムは私が作ったのではなかったが、すでに担当者は辞めていたので直すことになった。遅い箇所がどこなのかを調べるためプログラムの要所要所で時間を測る事にした。
すると、あるデータの登録時に異様に長い時間が掛かっているのが判った。たった7件のレコードを登録するのに2秒近く掛かっている。
他の箇所は数十から数百ミリ秒だから100倍以上遅い。なぜこうも時間を要するのか。

結論を言おう。
あるデータをテーブルに追加登録するのにadOpenStaticモード(静的カーソル)でオープンしていた。さらにwhere句を付けていないため、全レコード分のカーソルを取得するはめになる。これではデータが増えれば増えるほど時間が掛かる。
単純に追加登録するだけで全レコード数とか知る必要も無いのだからadOpenStaticを使う必要はない。実際にはdbOpenDynamicが効果が高いことが判った。
修正したところ10ミリ秒になった。つまり100倍以上も早くなったわけである。
調べていくとあちこちに同様の記述がある。これらを直せば相当改善されることだろう。

注：単純にdbOpenDynamicにすれば良いわけではない。効果があるのはCursorLocationがadUseServerの時でadUseClientではやはり時間がかかる。ただadUseServer時のdbOpenDynamicでは取得できないRecortCountがadUseClientにすると取得できる。

単純なことだが、意外と盲点で、知らず知らずやってることが結構あるんじゃないだろうか。導入当初はデータも少ないので問題に気が付かないが、データが増えていくに連れてじわじわ効果(?)が現れてくる。しかもデータが増えれば遅くなるのは当然だ、と自分を納得させてしまう。・・・・自分のことだ(^^;

Windowsにログオンしたあとプログラムを自動で起動させるには３つの方法がある。
・スタートアップに登録する方法
・レジストリ(CURRENT_USER)に登録する方法
・レジストリ(LOCAL_MACHINE)に登録する方法

さて、このうちどれが一番早く起動するだろうか。

実は今まであまり気にして無かったのでテストしてみることにした。
次のバッチファイルをそれぞれに登録してみた。

@echo off
echo これは○○○○
time

その結果は下のようになった。


１番：LOCAL_MACHINE
２番：CURRENT_USER
３番：スタートアップ

案外予想通りだったなぁ。

開発環境ではSQLServer2005を使っていた。
客先の実行環境ではSQLServer2000を使っている。

客先でデータベースを構築しているとき、テーブルの作成は問題無く出来たがViewの作成でエラーが起きた。
SQLServer2000のクエリアナライザからView作成のSQL文を実行させると

「行3：'(' の近くに無効な構文があります。」と出てViewの作成に失敗する。

一体どこが問題なのかさっぱり判らなかったのだが３行目にある
SELECT TOP (100) PERCENT ...... の１００のカッコを外したら
正常に作成された。

SQLSever2005のManagement Studioが作ったSQL文には自動でカッコ付きになっているが、これが原因だった。大した違いはないと思うが2000には分からないらしい。

客先のアプリケーションサーバー(Windows2003Server)にASP.NET2.0で作ったWebアプリケーションをインストールしたところ、既存のアプリケーションが動作不良になってしまった。
こちらはASP.NET 1.1を使ったものでこちらを有効にさせると今度は2.0の方が動かなくなってしまった。

イベントログを見たところ次のような記述があった。
「同じ IIS プロセスで、異なる 2 つのバージョンの ASP.NET を実行することはできません。サーバーを再構成して、異なるプロセスでアプリケーションを実行するには、IIS 管理ツールを使用します。 」

マイクロソフトのサイトに対応策が載っていた。
http://msdn.microsoft.com/ja-jp/library/1kdfe21k.aspx

説明文：
このエラーは、複数のバージョンの ASP.NET が同じプロセスを実行するように構成されている場合に発生します。これは、異なるバージョンの .NET Framework とランタイムは同じプロセス内で side-by-side 実行できないためです。このため、ランタイムの特定のバージョンを使用する ASP.NET アプリケーションは、異なるバージョンを使用するアプリケーションとプロセスを共有させないでください。一般的に、このエラーは、複数のアプリケーションが ASP.NET の異なるバージョンに割り当てられているのに、同じアプリケーション プールを共有するときに発生します。

つまり、アプリケーションプールを別に用意して割り当てれば良いということだ。
これを実行したところ、両バージョンとも正常に動作するようになった。

客先でAS400のデータをレガシーASPで利用する際、ODBC(iSeries Access for Windows ODBC)を利用したのだが、何故かエラーして繋がらなかった。
ACCESSを使ってテーブルのリンクをすると問題無く開くのに、ASPからだとエラーになってしまう。
その時のエラーが「[Microsoft][ODBC Driver Manager]データソース名および指定された既定のドライバが見つかりません」というものだった。
マイクロソフトのサポートページ http://support.microsoft.com/kb/306345/ja
をみてためしたがやはり駄目。
仕方なくその日は諦め、翌日同僚に状況を話したところ、システムDSNでないとASP側からは接続できないと指摘があった。なるほど、そうだ！ログインしたユーザーが操作するACCESSと違い、ASP経由では別のユーザーになっていることを忘れて、何も考えずユーザーDSNに登録していたのだ。
ということで、改めてシステムDSNに登録して無事解決した。

ASPでのODBC接続はシステムDSNを使わねばならない。

前回わけ在ってASP.NETではなく旧ASP(レガシーASP)で開発することになった顛末を紹介した。
ASP開発にはこれまでずっとVisualStudio6.0のInterDevを使っていたので今回も当然使った。ところが、データベースに接続するところでSQLServer2005には問題なく接続できるのに、Access2002(2000)にはどうやっても接続できない現象が現れた。しかも、InterDevを使わなければ接続できることもあるので困ってしまった。

そうしたなか、VisualStudio2005で使えないかと調べているうちに山田祥寛氏の記事(PDF)を見つけた。ほんの最近公開されたものであるが、そのなかにVisualStudio2008SP1では「レガシーASPの開発サポートを復活」と書かれているのを発見した。

さっそく無償のExpress版のVisual Web Developer 2008 Express Edition をダウンロードして使ってみたところ、素晴らしいではないか。見事にASPを統合環境で使える。しかも、InterDevではエラーしまくっていたのに、何も手を加えずとも全く問題なくAccessのデータが読めるようになった。

一時は、テキストエディターだけで開発しようかと思っていたのでVisualStudioの開発環境が使えることは大いに助かった。


ツールボックスにはHTML関係だけがある。
InterDevではデザイン画面がまともに開けることの方が少なかったがこちらはかなり使えそうだ。

今ASP.NETではなく以前によく作ったASPで開発している。
というのも、今回の開発では通常のパソコンで動くブラウザではなく、ハンディーターミナル(デンソーウェーブのBHT-500)で動くブラウザをターゲットとしているためだ。
最初はASP.NETでやるつもりだったのだが、あまりにレスポンスが悪いため断念せざるを得なかった。
もう４年以上ASPでは開発していないので戸惑うことしばしばであるが、レスポンスは抜群によい。もともとハンディーターミナルという小さい画面の表示文字数にも制限のある環境なのでデザイン的に凝ることもないのでASPで正解だった。

使ってみると確かにHTMLとプログラムが入り混じってごちゃごちゃした感じだが、ASP.NETのコントロールが自動的に作成するコードが無い分、こちらで記述したコードだけが最短で処理されている感じがして、実にキビキビと動く。
ASP.NETばかりでなく、システムによってはASPで開発することも考慮していいかも。

打ち合わせに行ってきた。
ユーザーの要望を聞き、現場を見、その都度思い出してはこうしたい、ああしたいと言うユーザーの話を聞き、とりあえずメモっておくが、何だかとんでもなく面倒な仕様に感じてくる。
聞きながら「きっと見積額が相当になるだろうなぁ」と思う。

会社に戻り、がっくり疲れて打ち合わせ内容をまとめるのも面倒になって、気晴らしをしているうちに時間がきて何もせずに仕事を終える。
次の打ち合わせまで一週間あるので、まだいいやと思って他の仕事をしているうちに数日何もそのことは考えずに過ごした。
そろそろまとめなければと思い、どうやるかを考えてみると、あれ？意外と見通しが立つ仕様になった。

最初の時に感じた面倒臭さはない。知らない間に余計な情報が消えて(忘れただけかも)主題だけが残った結果みたいだ。疑問点も具体化して次回の打ち合わせにちょうど良い。

楽して問題が解決するなんて！これって無意識の脳の働きなんだろうか？