- PR -

ASPとODBCを使った時のメモリ不足エラーについて

«前のページへ 1|2
投稿者投稿内容
OakBow
ベテラン
会議室デビュー日: 2007/09/15
投稿数: 51
投稿日時: 2008-01-12 18:48
引用:
Jet(Access)も、別に ODBC でもそんなに悪くはないとは思いますが、でも、ODBC 以外の方法があり、かつ、ADO に対して接続文字列をちょこちょこっと変えるだけ、それだけ、で済むのに、わざわざ ODBC を使う必要性もないと思います。


Accessに関してはそういう風潮は結構あるようですね。
個人的感覚では、安定して利用できる接続方式って認識があるので、利用を避けるべき積極的な理由があるかどうかが気になりました。
別にそういうわけではないようですね。返答ありがとうございます。

todo
ぬし
会議室デビュー日: 2003/07/23
投稿数: 682
投稿日時: 2008-01-12 21:10
http://support.microsoft.com/kb/832205/ja
OakBow
ベテラン
会議室デビュー日: 2007/09/15
投稿数: 51
投稿日時: 2008-01-12 21:39
あら、Access ODBC ドライバはスレッド セーフではないとありますね。
んじゃやっぱOLE DB Provider for Jetになるのか。

どっちにしろDB変えろって書いてありますけどね。。
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)
投稿日時: 2008-01-12 22:08
昔のことで良く覚えていないのですが、ここでの、スレッドセーフでない、というのは、作りがスレッドセーフではない、というのではなく、あんまりちゃんと作っていなくてバグ満載だからマルチスレッドで使わないでくれるとありがたい、ということをマイクロソフトは言いたかったのではなかったのではないか、と私は勝手に思っています。
(ミッションクリチカルなサーバー用途で使ってほしくない、というのと同じようなことです。)

大昔の IIS 3.0 の頃は、ASP 上で Jet(Access) を操作するには、「Microsoft OLE DB Provider for Microsoft Jet」がなく、Jet(Access)用の ODBC ドライバーと「Microsoft OLE DB Provider for ODBC Drivers」を使うしかなく、それでもそこそこ動いていたような記憶があります。

とはいえ、確証はありません。

どなたか、いまさらながら、マルチスレッド環境で検証してみてください。

＃以下、追記。

二重否定が変でした。
上記中、
「ということをマイクロソフトは言いたかったのではなかったのではないか」
じゃなくて
「ということをマイクロソフトは言いたかったのではないか」
です。

[ メッセージ編集済み 編集者: unibon 編集日時 2008-01-13 09:39 ]
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)
投稿日時: 2008-01-12 22:16
そういえば、大昔は「Internet Database Connector」なるものがありましたね。
.idc ファイルと .htx ファイルで、ODBC にアクセスするやつです。
IIS に付属するサンプルに Jet(Access)のデーターベースが付いていませんでしたっけ？

古すぎて良く思い出せませんが。
KAR
会議室デビュー日: 2007/02/19
投稿数: 11
投稿日時: 2008-01-13 13:01
私の初歩な質問から多大なるご意見・ご助言を頂きありがとうございます。

先の回答にて「ASPで公開するのが不安」とさせて頂いたのは
todo様がお知らせ頂きましたURLの内容に起因致します。

ですがunibon様の見解などを読ませて頂いたところ
確かに「Accessは公開するデータベースには不向きである」と
遠回しに言っているように感じました。

やはり以前ご教授頂いたように「SQL SERVER」への移行を
今後は善処させて頂きたい思います。

それまでは「JETエンジン」を使って構築して行きたいと思います。
ぴんふ
ベテラン
会議室デビュー日: 2006/07/13
投稿数: 80
投稿日時: 2008-01-15 12:04
こんにちは。ぴんふです。

技術面で言うと・・。
KARさんが予測されている原因について検証してみてはいかがでしょうか。
１．ODBCから読み込むデータが多い
→データ量を減らして動作させてみる。これで問題なく動作したのであれば
RDBMSの変更、接続方法の変更を検討すべきでしょう。
２．SQL命令の条件が多く処理が複雑の為メモリを使用している
→SQLを単純化して動作させてみる。これで問題なく動作したのであれば
APの構成変更（SQLで行っている部分をビジネスロジックに置き換え）で対応できるかも。
３．ODBCの構成からバッファサイズが足りていない
→バッファサイズを増やしてみる（やり方知りませんが・・・）

要件面で言うと・・。
トラヒック量、データ量の予測・検討をした上でAccess、ODBC接続を選択されたのでしょうか？
原因を判明させた後にユーザへの相談・提案をすべきだと思います。
«前のページへ 1|2

スキルアップ／キャリアアップ（JOB@IT）