C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[7]: データベース接続の共有

(過去ログ 84 を表示中)

[トピック内 21 記事 (1 - 20 表示)]　 << 0 | 1 >>

■49671 / inTopicNo.1)

　データベース接続の共有

▼■

□投稿者/ らーじ (12回)-(2010/05/12(Wed) 18:30:40)

分類:[VB.NET/VB2005 以降]　

EXEごとに同じmdbに接続する処理を行っており、そのEXEが終了するときに接続を切断しています。

この方法だと、画面が起動、終了する時に遅くなってしまいます。
mdbへの接続を共有する方法はありますでしょうか。

引用返信 編集キー/

■49675 / inTopicNo.2)

　Re[1]: データベース接続の共有

▲▼■

□投稿者/ .SHO (1330回)-(2010/05/12(Wed) 21:42:30)

■No49671 (らーじさん) に返信
> EXEごとに同じmdbに接続する処理を行っており、そのEXEが終了するときに接続を切断しています。
>
> この方法だと、画面が起動、終了する時に遅くなってしまいます。
> mdbへの接続を共有する方法はありますでしょうか。

mdbへの接続を受け持つEXEを1つ裏で起動しておき、他のEXEはそいつと接続するとか。

引用返信 編集キー/

■49679 / inTopicNo.3)

　Re[2]: データベース接続の共有

▲▼■

□投稿者/ 渋木宏明(ひどり) (1329回)-(2010/05/13(Thu) 00:02:34)

> mdbへの接続を受け持つEXEを1つ裏で起動しておき、他のEXEはそいつと接続するとか。

そして、それを自力で構築＆保守する手間考えたら、早々に SQL Server Express 辺りに乗り換えた方が幸せな予感。

引用返信 編集キー/

■49681 / inTopicNo.4)

　Re[3]: データベース接続の共有

▲▼■

□投稿者/ らーじ (13回)-(2010/05/13(Thu) 09:48:52)

ありがとうございます。
初心者で申し訳ありません。
一般的によくある、メニュー画面があってそこから各機能の画面が出るようなアプリは各機能ごとにプロジェクトを作成していると思われますが、質問のようなデータベースへの接続等の共通の処理はどのように行っているのでしょうか。

やはり裏でEXEが動いていてその接続を利用しているんですか？

引用返信 編集キー/

■49688 / inTopicNo.5)

　（削除）

▲▼■

□投稿者/ -(2010/05/13(Thu) 11:22:34)

この記事は(管理者)削除されました

引用返信 編集キー/

■49689 / inTopicNo.6)

　Re[5]: データベース接続の共有

▲▼■

□投稿者/ 中博俊 (1399回)-(2010/05/13(Thu) 11:22:53)

＞一般的によくある、メニュー画面があってそこから各機能の画面が出るようなアプリは各機能ごとにプロジェクトを作成していると思われますが、質問のようなデータベースへの接続等の共通の処理はどのように行っているのでしょうか。

いえ通常1EXEでコネクションプーリングを利用しています。
まずその設計を何とかするべきでしょうね。

引用返信 編集キー/

■49693 / inTopicNo.7)

　Re[6]: データベース接続の共有

▲▼■

□投稿者/ らーじ (14回)-(2010/05/13(Thu) 12:02:04)

■No49689 (中博俊さん) に返信
> ＞一般的によくある、メニュー画面があってそこから各機能の画面が出るようなアプリは各機能ごとにプロジェクトを作成していると思われますが、質問のようなデータベースへの接続等の共通の処理はどのように行っているのでしょうか。
>
> いえ通常1EXEでコネクションプーリングを利用しています。
> まずその設計を何とかするべきでしょうね。

ありがとうございます。
現状、各EXEで1つのコネクションプーリングを作成しています。（EXEは各ユーザーのCドライブにあり、それを起動します。）
EXE起動、終了の際に重い感じがし、処理にも少々時間がかかります。

ということは、アプリ側の問題ではなく、HW的な問題ということなのでしょうか？

P.S　最初に書いた「EXEごとに同じmdbに接続する処理を行っており、そのEXEが終了するときに接続を切断しています。」という設計は間違っていないという認識でいいのでしょうか。

引用返信 編集キー/

■49694 / inTopicNo.8)

　Re[7]: データベース接続の共有

▲▼■

□投稿者/ はつね (1266回)-(2010/05/13(Thu) 12:21:41)

2010/05/13(Thu) 12:22:49 編集(投稿者)

■No49693 (らーじさん) に返信
> 現状、各EXEで1つのコネクションプーリングを作成しています。（EXEは各ユーザーのCドライブにあり、それを起動します。）

複数のEXEにまたがってコネクションプーリングって維持されましたっけ？
というか、mdbに対してコネクションプーリングって効きましたっけ(OLE DBで接続？）？

引用返信 編集キー/

■49695 / inTopicNo.9)

　Re[8]: データベース接続の共有

▲▼■

□投稿者/ なちゃ (430回)-(2010/05/13(Thu) 12:50:19)

画面毎に別EXEにするのが、間違ってるとは言いませんけどあまりおすすめできません。

それで小細工するくらいなら、DLLにしてひとつのプロセス内で動かします。

引用返信 編集キー/

■49697 / inTopicNo.10)

　Re[9]: データベース接続の共有

▲▼■

□投稿者/ かたぎり (23回)-(2010/05/13(Thu) 13:09:42)

コネクションプーリングってプロセス間で共有できたかしらん？
SQLServerだと、DB側で再利用を考慮してくれるので求める結果に近い動きになるかもですけれど。

設計しなおしを検討されているのであれば、そこから考え直しでも良いのかもです。
ただ、色々と背景があったり、大人の事情はあったりしますから、
MDB使うなら使うで、使うなりの設計をすれば問題はないと思うし、
ベストが無理ならベターの方法をさがしていくしかないですものね。

ということで、MDBのままでいくなら、なちゃさんの意見に賛成します。

１ソリューションプロジェクトにまとめなおして、
１exe画面処理をDLLライブラリにプロジェクトの種類を変更して
DBアクセス部分を１DLLに切りだしてライブラリにして
スタートアップ画面を設定しなおせば、だいたいの基礎作業は終わりそうな予感です。
といってもソースとプロジェクトみたわけじゃないので、憶測になりますけれども。

引用返信 編集キー/

■49698 / inTopicNo.11)

　Re[7]: データベース接続の共有

▲▼■

□投稿者/ エクシ (16回)-(2010/05/13(Thu) 14:16:35)

■No49693 (らーじさん) に返信
EXE起動とか言っている時点で、.NET アプリの起動が遅いのが原因かもしれないし、
>EXE起動、終了の際に重い感じがし、処理にも少々時間がかかります。
>ということは、アプリ側の問題ではなく、HW的な問題ということなのでしょうか？
・原因を特定できていない
・何を基準に遅いといっているのか不明(具体的な数値が一切出ていない)
それが仕方ないレベルなのか、改善点があるのかも分からないです。
その状態で議論したところで８割がた徒労に終わります。

>P.S　最初に書いた「EXEごとに同じmdbに接続する処理を行っており、
>そのEXEが終了するときに接続を切断しています。」という設計は
>間違っていないという認識でいいのでしょうか。
同じ MDB に接続する同様の処理は１つの EXE にします。
その EXE が１つの接続を使います。
その点だけ見れば間違っていないように思います。
(接続だけ別 EXE を作るような必要に迫られた経験は過去8年間1度もありません。)

しかし全体の設計が合っているのか間違っているのかは、今まで提示された
内容からは判断できませんでした。

接続を別にして、検索処理が遅いとか言う話であれば、テーブル設計が悪いことも考えられます。
大量データを扱っていて、処理時間的に切り詰められないのであれば、データを見直し、
検索時に差分だけ取ったり、マスタの情報などは更新命令を画面の操作で出すまでは
使いまわす(検索に行かない)などの工夫も必要かもしれません。
･･･そもそも接続だけが遅い原因とは限りません。

>初心者で申し訳ありません。
その言葉を言うのは簡単ですが、こちらには「解決する意思がありません」と
聞こえる場合がありますので、押し殺して口にせずに努力してください。

引用返信 編集キー/

■49706 / inTopicNo.12)

　Re[9]: データベース接続の共有

▲▼■

□投稿者/ らーじ (15回)-(2010/05/13(Thu) 16:36:19)

■No49695 (なちゃさん) に返信
> 画面毎に別EXEにするのが、間違ってるとは言いませんけどあまりおすすめできません。
>
> それで小細工するくらいなら、DLLにしてひとつのプロセス内で動かします。
>

ありがとうございます。

画面毎に別のEXEというとちょっと違うような気もします。
例えば社員情報管理アプリというのがあったとして、社員登録・変更・削除で一つのEXE、社員検索で一つのEXE、社員一覧を印刷するEXEが一つという感じでしょうか。
社員検索のEXEで部署を選択する画面、性別を選択する画面等があったとしても社員検索のEXEに含みます。

この場合、社員登録・変更・削除でもHoge.mdbに接続しますし、社員検索でも、社員一覧でもHoge.mdbに接続する必要があるかと思います。
なので現状をこの場合に置き換えて言うと、それぞれのEXEが起動した際にForm_Load等でmdbへの接続を行っています。

ただ、社内のPCがそれほど快適なものではないためか、起動、終了時に1～2秒画面がちらつき、画面の遷移がスムーズではありません。
(WinXP SP2 メモリ512MB　5年前購入）

既にリリースされたものであり、今からの仕様の変更はできません。

dllとするとしても、dll自体が保持してくれるわけではなくインスタンスが保持するわけなので毎回EXE起動した際にインスタンスを作成したらNewされてしまうような気がするんですが･･･。

引用返信 編集キー/

■49707 / inTopicNo.13)

　Re[10]: データベース接続の共有

▲▼■

□投稿者/ エクシ (17回)-(2010/05/13(Thu) 17:13:02)

■No49706 (らーじさん) に返信
>画面毎に別のEXEというとちょっと違うような気もします。
こちらの基準で言えば同じでしょうね。1画面が2･3画面になったところで、
複数の EXE からのアクセスが発生するという観点から見れば同じです。

もともと、MDB にマルチユースを許すのは、タブーだと認識しています。
[Fly Me To The Access-Heaven]
http://www.naboki.net/access/achell/achell-02.html
もともと、MDB 相手にそんな設計でプログラムを組むことが稀ですね。

>> それで小細工するくらいなら、DLLにしてひとつのプロセス内で動かします。
> dllとするとしても、dll自体が保持してくれるわけではなくインスタンスが
> 保持するわけなので毎回EXE起動した際にインスタンスを作成したらNewされて
> しまうような気がするんですが･･･。
おそらくは各機能(社員登録・変更・削除・社員検索・社員一覧印刷)を DLL 化し、
「社員情報管理アプリ」が全てを参照する形で１つの EXE にコンパイルしなおせ
という事です。

> ただ、社内のPCがそれほど快適なものではないためか、起動、終了時に1～2秒画面がちらつき
1～2秒なら VB のアプリとしては許容範囲内の気もしますが、ちらつきは
MDB 接続と関係ないかもしれません。

> 画面の遷移がスムーズではありません。
この画面とは、１つの EXE 内の「社員登録」→「社員変更」を差しますか？
別 EXE の「社員登録」→「社員一覧印刷」を差しますか？
別 EXE なら MDB 接続無くても遅くて不思議じゃない気がしますが、テスト
プログラムを作って実際に各ステップの処理時間は計測しましたか？

> 既にリリースされたものであり、今からの仕様の変更はできません。
それでは仮に、裏でEXEが動いていてその接続を利用するのが有効だと結論が
出ても、変更が難しいように考えるのですが？

引用返信 編集キー/

■49708 / inTopicNo.14)

　Re[11]: データベース接続の共有

▲▼■

□投稿者/ らーじ (16回)-(2010/05/13(Thu) 17:44:57)

■No49707 (エクシさん) に返信
> ■No49706 (らーじさん) に返信
> >画面毎に別のEXEというとちょっと違うような気もします。
> こちらの基準で言えば同じでしょうね。1画面が2･3画面になったところで、
> 複数の EXE からのアクセスが発生するという観点から見れば同じです。
>
> もともと、MDB にマルチユースを許すのは、タブーだと認識しています。
> [Fly Me To The Access-Heaven]
> http://www.naboki.net/access/achell/achell-02.html
> もともと、MDB 相手にそんな設計でプログラムを組むことが稀ですね。
>
マルチユース？どこからマルチユースだと思われたのでしょう。複数人がアクセスすることはないですし、最初に画面1でマスタを取得し、画面2、3は表示しているだけなのでではアクセスはしてません。

> >> それで小細工するくらいなら、DLLにしてひとつのプロセス内で動かします。
>>dllとするとしても、dll自体が保持してくれるわけではなくインスタンスが
>>保持するわけなので毎回EXE起動した際にインスタンスを作成したらNewされて
>>しまうような気がするんですが･･･。
> おそらくは各機能(社員登録・変更・削除・社員検索・社員一覧印刷)を DLL 化し、
> 「社員情報管理アプリ」が全てを参照する形で１つの EXE にコンパイルしなおせ
> という事です。

クラスライブラリってフォーム作れましたっけ？？
>
>>ただ、社内のPCがそれほど快適なものではないためか、起動、終了時に1～2秒画面がちらつき
> 1～2秒なら VB のアプリとしては許容範囲内の気もしますが、ちらつきは
> MDB 接続と関係ないかもしれません。
>
DB接続をしない場合でテストしてみましたが、その場合はちらつきはなかったです。（起動して終了するのみのテスト）

>>画面の遷移がスムーズではありません。
> この画面とは、１つの EXE 内の「社員登録」→「社員変更」を差しますか？
> 別 EXE の「社員登録」→「社員一覧印刷」を差しますか？
> 別 EXE なら MDB 接続無くても遅くて不思議じゃない気がしますが、テスト
> プログラムを作って実際に各ステップの処理時間は計測しましたか？

各EXEの終了時及び別にメニュー画面があり、そこから各EXEの起動です。

>
>>既にリリースされたものであり、今からの仕様の変更はできません。
> それでは仮に、裏でEXEが動いていてその接続を利用するのが有効だと結論が
> 出ても、変更が難しいように考えるのですが？

大規模なシステムではなく、ただ個人的にツールのような感覚で作っただけなので、設計もほとんどないですし、現状から一番ベターな方法は何かという質問です。

引用返信 編集キー/

■49711 / inTopicNo.15)

　Re[12]: データベース接続の共有

▲▼■

□投稿者/ みきぬ (890回)-(2010/05/13(Thu) 18:31:46)

■No49708 (らーじさん) に返信
> >>ただ、社内のPCがそれほど快適なものではないためか、起動、終了時に1～2秒画面がちらつき
>>1～2秒なら VB のアプリとしては許容範囲内の気もしますが、ちらつきは
>>MDB 接続と関係ないかもしれません。
>>
> DB接続をしない場合でテストしてみましたが、その場合はちらつきはなかったです。（起動して終了するのみのテスト）
>
DB の接続/切断を非同期でやるとか。

引用返信 編集キー/

■49712 / inTopicNo.16)

　Re[12]: データベース接続の共有

▲▼■

□投稿者/ エクシ (18回)-(2010/05/13(Thu) 18:39:25)

■No49708 (らーじさん) に返信
> マルチユース？どこからマルチユースだと思われたのでしょう。複数人がアクセスすることはないですし
マルチユーザではなく、マルチユースです。ユーザが同じだというだけで、複数のプロセスから
アクセスしているのですから、同じ問題点を含みます。

> 最初に画面1でマスタを取得し、画面2、3は表示しているだけなのでではアクセスはしてません。
このスレで質問されているのは、別 EXE にて MDB に接続することが問題となっていたはず
です。同じ EXE 内であれば同じインスタンスを使いまわせるのでしょう？問題ないのでは？
別 EXE (別プロセス)にて起動した画面では、同じ MDB にアクセスしていますね？
> 画面2、3は表示しているだけなのでではアクセスはしてません。
この表現には該当しません。

> クラスライブラリってフォーム作れましたっけ？？
フォームを作るのはあくまでメインルーチンである「社員情報管理アプリ」だと思いますが、
クラスライブラリにフォームを登録しておいて利用することは可能です。

> DB接続をしない場合でテストしてみましたが、その場合はちらつきはなかったです。（起動して終了するのみのテスト）
了解です。

> 各EXEの終了時及び別にメニュー画面があり、そこから各EXEの起動です。
了解です。
それぞれのステップでの処理時間は？
別 EXE を起動して終了してしまうのでは処理時間を計測するのが難しいような気が
しますが、そのあたりは修正して計測してください。EXE 起動に何秒掛かっていて、
そのうち MDB 接続には何秒掛かっていますか？

> 既にリリースされたものであり、今からの仕様の変更はできません。
この説明では、貴方の意思に反して大人の事情があり、設計の変更はできないとなります。
> 大規模なシステムではなく、ただ個人的にツールのような感覚で作っただけなので、
> 設計もほとんどないですし、現状から一番ベターな方法は何かという質問です。
この説明では、貴方の作成したプログラムなので、貴方の意思があれば設計レベルでの
変更も可能と聞こえます。
･･･どちらが正しい説明ですか？

引用返信 編集キー/

■49713 / inTopicNo.17)

　Re[13]: データベース接続の共有

▲▼■

□投稿者/ らーじ (17回)-(2010/05/13(Thu) 19:11:42)

2010/05/13(Thu) 19:12:52 編集(投稿者)

■No49712 (エクシさん) に返信
> ■No49708 (らーじさん) に返信
>>マルチユース？どこからマルチユースだと思われたのでしょう。複数人がアクセスすることはないですし
> マルチユーザではなく、マルチユースです。ユーザが同じだというだけで、複数のプロセスから
> アクセスしているのですから、同じ問題点を含みます。
>
複数のプロセスというとどこでしょう？EXEが起動するときに接続、終了するときに切断ですから、複数プロセスからアクセスすることはありません。
メニューから複数画面を起動することはできません。（先ほどの例で、登録画面を起動したまま、検索画面は起動できません。）

>>最初に画面1でマスタを取得し、画面2、3は表示しているだけなのでではアクセスはしてません。
> このスレで質問されているのは、別 EXE にて MDB に接続することが問題となっていたはず
> です。同じ EXE 内であれば同じインスタンスを使いまわせるのでしょう？問題ないのでは？
> 別 EXE (別プロセス)にて起動した画面では、同じ MDB にアクセスしていますね？
>>画面2、3は表示しているだけなのでではアクセスはしてません。
> この表現には該当しません。
>
>>クラスライブラリってフォーム作れましたっけ？？
> フォームを作るのはあくまでメインルーチンである「社員情報管理アプリ」だと思いますが、
そうすると、結局EXEは社員情報管理アプリ.exeのみということになります。だとすれば、Publicで定義しておけば接続の使いまわしは可能だと思いますが。

> クラスライブラリにフォームを登録しておいて利用することは可能です。
>
>>DB接続をしない場合でテストしてみましたが、その場合はちらつきはなかったです。（起動して終了するのみのテスト）
> 了解です。
>
>>各EXEの終了時及び別にメニュー画面があり、そこから各EXEの起動です。
> 了解です。
> それぞれのステップでの処理時間は？
> 別 EXE を起動して終了してしまうのでは処理時間を計測するのが難しいような気が
> しますが、そのあたりは修正して計測してください。EXE 起動に何秒掛かっていて、
> そのうち MDB 接続には何秒掛かっていますか？
>
調査中。
>
>
>>既にリリースされたものであり、今からの仕様の変更はできません。
> この説明では、貴方の意思に反して大人の事情があり、設計の変更はできないとなります。
>>大規模なシステムではなく、ただ個人的にツールのような感覚で作っただけなので、
>>設計もほとんどないですし、現状から一番ベターな方法は何かという質問です。
> この説明では、貴方の作成したプログラムなので、貴方の意思があれば設計レベルでの
> 変更も可能と聞こえます。
> ･･･どちらが正しい説明ですか？

意思はあっても時間がないです。これだけを仕事としているわけではないので。
ご回答にもあるようにベストな方法でなくてもいいので、より良くなればOKです。
とは言え、画面がちらつくから使いもんにならないとか、誰かに迷惑かかるとかいう問題でもないので上記のように何秒かかって…等そこまで追い求める気はなかったです。
必要だというのであれば調査します。

終了する時にちらつくことが判明して、終了時の処理は接続を切断するしかやっていなかったので、そこに原因があるだろうと感覚的に思った次第です。

引用返信 編集キー/

■49715 / inTopicNo.18)

　Re[14]: データベース接続の共有

▲▼■

□投稿者/ エクシ (19回)-(2010/05/13(Thu) 19:45:33)

■No49713 (らーじさん) に返信
> メニューから複数画面を起動することはできません。
あー、そうしてるんだ？EXE って言えば実行ファイルだから、単体起動できる事が基本で、
例えばエクスプローラからダブルクリックで起動することが常識だと思っていたので、
複数 EXE の時点でマルチ機能があるものと誤解していました。

> そうすると、結局EXEは社員情報管理アプリ.exeのみということになります。
> だとすれば、Publicで定義しておけば接続の使いまわしは可能だと思いますが。
そうですよ？その具体的な方法が、■49697 かたぎりさんの
>１ソリューションプロジェクトにまとめなおして、
>１exe画面処理をDLLライブラリにプロジェクトの種類を変更して
>DBアクセス部分を１DLLに切りだしてライブラリにして
>スタートアップ画面を設定しなおせば、だいたいの基礎作業は終わりそうな予感です。
でしょう？
ある程度プログラムに慣れていれば１日あればできない作業では無い気がしますが。。。
基本、処理の流れは変わらないわけですし。

> 意思はあっても時間がないです。これだけを仕事としているわけではないので。
それを言うなら、私はそのまま何もしない推奨。

> 上記のように何秒かかって…等そこまで追い求める気はなかったです。
> 必要だというのであれば調査します。
それはまぁ、いいんだけど、現象と原因のつながりがある程度把握できないと、
修正したけど効果はありませんでしたって結果になるのでは？それはありなの？

ただ、画面の表示と DB 検索って直接関係ないから、それでちらつくとなると、
DB 検索があまりに遅くて OS の描画に影響を与えてる？･･･いやいや、基本、
プログラムの処理中は再描画されないから、やっぱり何かもう１つ原因が
特定されていない気がします。。。
とはいえ、■49711 みきぬさんの非同期処理。古くからの表現はマルチスレッド。
VB2005 以降は BackgroundWorker を調べてみる価値はあるのかも。

引用返信 編集キー/

■49716 / inTopicNo.19)

　Re[15]: データベース接続の共有

▲▼■

□投稿者/ はつね (1267回)-(2010/05/13(Thu) 22:03:44)

■No49715 (エクシさん) に返信
> >１ソリューションプロジェクトにまとめなおして、
> >１exe画面処理をDLLライブラリにプロジェクトの種類を変更して
> >DBアクセス部分を１DLLに切りだしてライブラリにして
> >スタートアップ画面を設定しなおせば、だいたいの基礎作業は終わりそうな予感です。
> でしょう？
> ある程度プログラムに慣れていれば１日あればできない作業では無い気がしますが。。。

修正はまだしもテストは自動テストとかじゃなければ１日じゃ足りないかもですよ。

>>意思はあっても時間がないです。これだけを仕事としているわけではないので。
> それを言うなら、私はそのまま何もしない推奨。

すごく同意＞何もしない推奨
やりたい事を実現するための時間（コスト）がやりたい事と見合うかどうかは人それ
ぞれでしょうから、見合わなければ何もしないのがいいですね。

引用返信 編集キー/

■49718 / inTopicNo.20)

　Re[14]: データベース接続の共有

▲　■

□投稿者/ .SHO (1334回)-(2010/05/13(Thu) 22:55:22)

■No49713 (らーじさん) に返信

> 複数のプロセスというとどこでしょう？EXEが起動するときに接続、終了するときに切断ですから、複数プロセスからアクセスすることはありません。
> メニューから複数画面を起動することはできません。（先ほどの例で、登録画面を起動したまま、検索画面は起動できません。）

だったら、メニューのEXEをmdbと繋げて、メニューから起動されたEXEはメニューと
やりとりしたらどうですか？

引用返信 編集キー/

次の20件＞
トピック内ページ移動 / << 0 | 1 >>

- Child Tree -