Discussion:
データベースが突然読み取り専用になる件
(too old to reply)
unknown
2008-10-16 09:03:01 UTC
Permalink
実行時エラー番号3051の「読み取り専用エラー」について、
各所でさんざん登場していますが、
当方の状況と合致するものが見当たらないので、
原因、対応策をご教授いただける方がいらっしゃいましたら
よろしくお願いいたします。

・構成
1つのMDBファイルをデータベースファイル(以下DBファイル)とし、
もう1つのMDBファイル(以下PGファイル)にDBファイルの全テーブルへ
リンクテーブルを張って、PGファイルでVBA、クエリ、フォーム、レポートを
動かして処理を行っています。
PGファイルは複数の者が各自自分の端末にコピーして設置し、実行します。
DBファイルはサーバー(WindowsServer2003)にあります。
もちろんDBファイルには複数人が同時にアクセスすることになります。

・両ファイルの設定
DBファイル、PGファイルとも、「既定の開くモード」は共有モード、
「既定のレコードロック」は編集済みレコード、
「レコードレベルでロックして開く」をONにしています。
「既定のファイル形式」はともにAccess2000です。
PGファイルをユーザーに渡しているわけですが、
ここらの設定を変更する者はいません。
テーブルに対して権限の設定などはしていません。

・Windows上の設定
DBファイルはサーバーの共有フォルダにあります。
フォルダもファイルも、ドメインのEveryone完全フルアクセスです。
後述のとおり常時の症状ではないので、この点については問題なしとして
切り分けられると考えています。

・PGファイルを使用している端末の設定
Officeのインストール状況やネットワークにおける設定等に
端末間の差異はありません。

・発生する不具合
使用中に突然、上記のエラーが発生します。
「突然」というのは、起動しっぱなしで朝から普通に動かしていて、
ある処理(不特定です)を行ったとき突然、という意味です。
エラー箇所はレコードセットのEdit部分がほとんどです。
(確認するときはいつもEditですが、後述の現状対応策をユーザーに伝えており、
 ユーザー側で対応してしまっているときは見ていないので、「ほとんど」としました。)
症状発生時にDBファイルを直接開こうとすると、
「読み取り専用のため更新等はできません。」(全文ではないですがご容赦ください)
と表示されます。開くことはできますが、編集はできません。
発生する処理はランダムで特定できませんが、
レコード数の大きいテーブルをいくつも使う処理など、重めの処理のとき、
あるいはそれが複数バッティングしたときが多いようです。

・現状対応策
構成に記載の通り複数人で使っていますので、全員にPGファイルを閉じてもらいます。
するとDBファイルを開くときに上記のメッセージが出なくなるので、
再度みんなに使用を開始してもらいます。すると正常に戻っています。
エラーになった時に行っていた処理を行っても今度は平気です。

足りない情報がありましたらご指摘ください。
なお記載の通り、フォルダ・ファイルのアクセス権とか端末の環境等については
問題がないものとしてご回答いただけることを望んでいます。
しつこくて申し訳ないですが、
 ・いつもは正常なものが突然不具合が発生する、
 ・これらの環境を一切変えなくても発生するし、復旧もする、
ので、Accessの問題でないと納得できないんです。
(念のためですが、DBファイルを置いているサーバーにWindowsの更新がかかったとか、
そういうタイミングではありません。)
ですので、そういうことに焦点を当てるのは避けてほしいです。
もちろん、それしか考えられない、又は明確にそこに原因があるというのであれば
仕方がありませんが・・・

長くなってしまいましたが、皆様のお知恵をお待ちしています。
TAKAHASHI Hisanori
2008-10-16 09:17:39 UTC
Permalink
DB$B%U%!%$%k!"(BPG$B%U%!%$%k$H$b!"!V4{Dj$N3+$/%b!<%I!W$O6&M-%b!<%I!"(B
$B!V4{Dj$N%l%3!<%I%m%C%/!W$OJT=8:Q$_%l%3!<%I!"(B
$B!V%l%3!<%I%l%Y%k$G%m%C%/$7$F3+$/!W$r(BON$B$K$7$F$$$^$9!#(B
$B%m%C%/$7$J$$@_Dj$G1?MQ$7$F$_$F$O$$$+$,$G$7$g$&!#(B
$B%P!<%8%g%s$OK:$l$^$7$?$,!"%"%/%;%9$G%l%3!<%I%m%C%/$9$k$H(B
$B$=$NA08e$N%l%3!<%I$b%m%C%/$5$l$k$H$$$&$N$rJ9$$$?$3$H$,$"$j$^$9!#(B
--
TAKAHASHI Hisanori
ken
2008-10-16 09:31:16 UTC
Permalink
あるユーザーが編集中なのに別のユーザーが同じデータを編集しようとするからではないでしょうか?
unknown
2008-10-16 10:50:01 UTC
Permalink
TAKAHASHI様、ken様

ご返信ありがとうございます。
さっそくご意見を頂けたので、
ご指摘を十分に試しもしないうちでのご返答、ご容赦ください。

TAKAHASHIさんのおっしゃる「ロックしない設定で運用」は
実際に試すのは慎重に行わないといけないので、すぐには行えませんが、

「レコードレベルでロック」のところで引っかかるのなら、
そのテーブルと、そのテーブルを使用しているフォーム等のオブジェクトに
限られると思うのですが、この考えは間違っていますでしょうか。
ひとたびこの状態に陥ると、DBファイル自体が直接開けなくなるので、
ファイル自体が読み取り専用になってしまっていると思います。
仮に発端となるテーブルがあったとして、その他のテーブルへの編集処理も
できなくなり、全員いったん閉じるという対応に陥るので、
レコードレベル、テーブルレベルではないと考えているのですが、
この考えが間違っているということでしたら、ご指摘ください。

簡単に以下の構成でテストしてみました。
・ファイルAに2つのテーブルを用意
・そのテーブルへのリンクを張った2つのファイルB,Cを用意
・編集ロック等の条件は質問で書いたのと同じ
<テスト1>
ファイルBでこのテーブルを開き、特定のレコードを編集途中で
(鉛筆マークの状態で)、ファイルCからもこのテーブルを開く
→開ける。ファイルBで編集中のレコードは編集できないが、
他のレコードは編集できる。ファイルAを直接開き、テーブルを開くときも同じ。
<テスト2>
ファイルBでこのテーブルをレコードセットにadLockReadOnlyで
開いては閉じる、という無限ループを実行し、
その後にファイルCで、AddNewでこのテーブルのフィールドに値を追加する、
という無限ループを実行する
→レコードはきちんと追加される。両方の無限ループ中に
ファイルAを直接開くと開けるし、テーブルも開ける、編集もできる。
(レコード数は300万件を超えていた)。
<テスト3>
編集ロックを「ロックしない」にして、テスト1を実行してみる
→どちらの変更を適用するか、などの確認メッセージが出るが、
基本的には同時でも変更できる。

テスト1とテスト3は設定どおりと受け止めています。
テスト2の結果を考えると、ファイル固有の問題ではないかと推測します。
SETO Sohei
2008-10-16 22:30:38 UTC
Permalink
$B$*$D$+$l$5$^$G$9!#(B
$***@b$O8e=R$7$^$9$,(B, Access$B!J$H$$$&$+(BJet $B!K$NLdBj!&;EMM$G$9!#(B

Access $B$OFC$K%M%C%H%o!<%/6&M-$G$N%^%k%A%f!<%6MxMQ$K$O8~$$$F$$$^$;$s!#(B
$BBgEl$5$s$KBP$9$k>lEv$?$jE*$JBP1~$H$7$F$O(B
$B!V%P%C%/%"%C%W$H:GE,2=$r$3$^$a$K9T$&$3$H$G(B, $B%j%9%/$O7Z8:$5$l$^$9!W(B
$B$G$"$j(B, $B$=$7$F:G$bE,@Z$J2r$O(B
$B!V%G!<%?%Y!<%9%(%s%8%s$r(BSQL Server$BEy$N%"%C%W%5%$%8%s%0$7$F2<$5$$!W(B
$B$K$J$j$^$9!#%f!<%6%$%s%?%U%'!<%9Ey$N%U%m%s%H%(%s%I$O(B Access $B$N$^$^$G(B
$B7k9=$G$9!#(B

* * * *

$B:#2s$NLdBj$H860x$H;W$7$-$b$N$H(B, $BA0CJ$NM}M3$r$***@bL@$7$^$9!#(B
$B!J%P!<%8%g%s$,=q$+$l$F$J$+$C$?$N$G$9$,(B Jet$B$K6&DL$NOC$G$9(B)

[ACC2003] Jet 4.0 $B%G!<%?%Y!<%9$NF0:n4D6-$r:GE,$KJ]$DJ}K!(B
http://support.microsoft.com/kb/303528/JA/

$B>e5-J8=q$+$iH4?h$G$9$,(B, $BFC$K(BJet$B%G!<%?%Y!<%9%(%s%8%s$NFC@-$H$7$F(B

(1) Jet$B$N%l%3!<%I%m%C%/$O(B, $B87L)$K$O%l%3!<%IC10L$N%m%C%/$G$O$J$/(B,
$B!!%U%!%$%k%7%9%F%`$N%Z!<%8!J(B4096$B%P%$%H!KC10L$G$N5<;w%m%C%/$G$"$k!#(B

(2) $B%U%!%$%k6&M-7?%G!<%?%Y!<%9$G$O(B, $B%U%!%$%k$r%/%i%$%"%s%HB&$G=hM}$9$k!#(B
$B!!$D$^$j%M%C%H%o!<%/7PM3$GJ#?t$N%W%m%;%9$,!J8D!9$K!K%m%C%/$r<B9T$9$k$N$G(B
$B!!8D!9$N%/%i%$%"%s%H>e$G$3$3$KDO$s$G$$$k$N(B*$B%W%m%;%9(B*$B$,=*N;$7$J$$8B$j(B,
$B!!%U%!%$%k$,IT40A4$J>uBV$^$?$OGKB;$7$?>uBV$K$J$k!#(B

$B$J$N$G(B, $B:#2s$N;vBV$O5/$3$k$Y$/$7$F5/$-$F$$$k8=>]$G$9!#(B

* * * *

Jet $B$H$$$&%G!<%?%Y!<%9%(%s%8%s$O$$$o$P(B, $B%m%C%/$N87L)@-$r5>@7$K$7$F(B,
$B!&%W%m%;%9!J>oCs%5!<%S%9$G$OL5$/(B, $B%"%W%j%1!<%7%g%s!K(B
$B!&J*M}5-210h!J;}$A1?$S2DG=$JC10l%U%!%$%k!K(B
$B$N4JN,2=!&5!F0@-$r<B8=$7$F$$$k!V;EMM!&%]%j%7!<!W$J$N$G$9!#(B

$B$h$j7xO4$G87L)$J6&M-!&GSB>%m%C%/$r<BAu$9$k$K$O(B, SQL Server$B$N$h$&$J(B
$BFC<l$J%5!<%S%9$*$h$S5-210h(BI/O$B$N;EAH$_$,I,MW$K$J$C$F$/$k(B, $B$H$$$&OC$G$9!#(B

$BD9$/$J$C$F$9$_$^$;$s$,(B, $B$3$s$J$H$3$m$G$4G<***@D:$1$^$9$G$7$g$&$+!#(B
--
SETO Sohei [ PGP Key ID:0x5DF0FA4D ]
Gobo-city, Wakayama, JAPAN
mailto: ***@creamy.nax.ne.jp
unknown
2008-10-17 00:18:00 UTC
Permalink
SETOさん

おはようございます。
大変詳細な説明をいただき、ありがとうございました。
また、非常に納得のいく理由でうれしい限りです。

データベースのSQLサーバー化は近々に行わなければならない
課題として認識していました。
早急に移行に取り掛かり、それまでの間はユーザーもこちらも少々
我慢して使っていこうと思います。

ご意見いただいた皆様もありがとうございました。
また何かありましたらよろしくお願いいたします。
Loading...