- - PR -
ADO接続にてMDB容量増加に伴うレスポンスの低下(VB.NET)
投稿者 | 投稿内容 | ||||||||
---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-10-21 08:52
正しくはこうなのではないでしょうか? 特に、Read メソッドの戻り値のチェックと、 Close メソッドの前の Null チェックは必須だと思います。
_________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 | ||||||||
|
投稿日時: 2005-10-21 09:30
確立可能なセッションが5までに制限されます。 コネクションをすぐ開放すればかなりの人数で共用できるかもしれません。 ただしMSのライセンスでは指名ユーザー5人ということになっていると思います。
WindowsであればInterbase(FireBird等)系かMySQLになるかと思います。 PostgreSqlもWindows版がありますが、業務で利用するのはまだ早そうです。 [ メッセージ編集済み 編集者: Anthyhime 編集日時 2005-10-21 09:31 ] | ||||||||
|
投稿日時: 2005-10-21 17:10
こんにちは、むさしです。
Accessさん、Beatleさん、じゃんぬねっとさん、Anthyhimeさん色々アドバイスありがとうございます。 >Beatleさん ASP.NETのようにWebアプリの場合サーバーがMDBとなるのでしょうか? Webアプリに携わったことがないのでなんともいえないのですが私の薄っぺらい感覚では 「ユーザーのアクション(ブラウザ)→SQL送信(IIS)→要求を返す(MBD)→結果を処理(IIS)→表示(ブラウザ)」 となっている部分がIISの部分はクライアント分処理をするので同じことかと思っていました。 っといっても全然しらない分野なので的外れな事を言っていたらすみません・・・(^_^; >じゃんぬねっとさん まったくもっておっしゃるとおりです! というより説明不足で申し訳ありません・・・実はデータ取得の際に「Dr.GetValue(x)」の部分にはVBAなどの数値型に使うnz関数(Nullがきた場合0を返す)と同じようなものを数値型と文字列型用でそれぞれ関数を用意し「Data.Name = nz(Dr.GetValue(0))」とすることで回避しています。 実際に値の入っていない場合は「""」で返せば表示したりするのには問題ないのでこのようにおこなっております。 じゃんぬねっとさんの書き方もあるのかと非常に勉強になりました! >Anthyhimeさん、Accessさん(別DBの件) 社内環境にてセキュリティポリシーの関係上勝手にDBサーバーを構築することが出来ず決まって提供されているサービスの範囲内でのみ利用可能との事でSQLServerやMSDEなどはNGでした・・・ かわりにAnthyhimeさんのおっしゃっていたMySQLが利用できるとの事で唯一残された道はそこにかかっているのかなという感じです。 MDBの構成をどう引き継ぐかにかかっていますが再利用性が低い場合は見送りとなる可能性もあるかと・・・ >Accessさん(データ件数の件) なんとこの話ですが・・・漢字を利用していて、Accessさんのアドバイスを元に修正を行い回線速度が速い場所で試験してみたところ同じ回線速度にもかかわらず15秒程度かかっていた表示処理が4,5秒になりました・・・ この差は大きく恐らく1分かかっていた回線速度のところであっても1/3〜1/4になることがわかりました。 検索内容などによっても短縮率は異なると思いますがこれだけのことでこんなにかわるとは驚きです・・・ とは言ったものの回線速度の遅いとこではまだまだストレスがたまる状態でみなさんからご指摘いただいていた同時アクセスの際の問題なども含めると引き続き悩ましい状態ではあります・・・ MySQLとMDBでそれぞれ調査をしてみる必要がありそうですね。 また関係ない話ですが、今回の開発にあたりAccessさん、じゃんぬねっとさんのページは非常によく参考にさせて頂きました、ありがとうございます。 またそのほかの皆さんのアドバイスも大変参考になっております、本当にありがとうございます。 | ||||||||
|
投稿日時: 2006-01-16 14:44
こんにちは、投稿者のむさしです。
以前は皆様のおかげで大変理解が深まりました、ありがとうございます。 作成していたシステムは4つのインスタンスで構成されるシステムで第一弾には間に合わなかったものの第二弾で成功する事ができました。 そこで分かった事をご報告いたします。 Accessさんのアドバイスからパス名に漢字が入っていた事が原因で遅くなっていたようで解消した結果4,5秒で表示に至ったもののそれでもまだ多少ストレスが残り引き続き調査をしてみたところ、別の方が作られた旧システムからの移行で元の仕様に疑いをもたず私自身あまりDBの知識がなかったもので分からなかったのですが、DBをメインにやっていた者の協力をあおいだところ抽出元のクエリがクエリからデータを取るという構成の仕方をしており通常DBを構成するうえでこういった構成のしかたはしないということでそこをなんとか1段で済ませれるようにしたところまさに1,2秒で表示となりました。 全く持ってお粗末な話かもしれませんが事例としてご報告いたします。 また何か分かりましたら書き込みしたいと思います。 |