ACCESSがクラッシュ？

質問

ＡＣＣＥＳＳ初心者です。
一応、対応できたので緊急ではありませんが非常に不思議な現象が発生しました。
もし原因や対応等についてご存知の方があればご教示願います。

経緯は時間を追って以下の通りのです。

１．ＡＣＣＥＳＳでシステムを開発（具体的にはメイン・サブフォームの作成）を行っていました。
２．一旦ウィザードでフォームを作った後、かなりあちこちをいじっておりました。いろいろなエラーメッセージが表示されていました。
３．突然、砂時計が出っ放しになってどこをクリックしても受け付けられなくなりました。
４．３０分以上待っていましたが全く変わらないため、やむを得ず強制終了をかけました。（前日にＤＢを別名でセーブしてあったのでそこからやり直してもいいと思っていました）
５．再度ＡＣＣＥＳＳを立ち上げ、当該フォームを呼び出すと「コンパイルエラー」が表示されＶＢＡが表示されましたが、それは作業中であったフォームではない、別のフォームのもののようです。
６．そのフォームをフォームビューで開いてもコンパイルエラーになるのはいいとして、同じＤＢ内の全く別のフォームを実行してもコンパイルエラーが出ます。
７．何をやってもエラーになり、表示されているＶＢＡの画面を見ると「 ate Sub ・・・・」等となっていてどうも元のコマンドの最初の方が消えてしまって不完全なコマンドになっているようです。
（当然私は初心者ですしそんなところを触った覚えも何もないのですが）
８．どうもＤＢ全体が壊れているようでした。ＡＣＣＥＳＳの場合はすぐに壊れるという話を聞いていましたので、このＤＢはあきらめて閉じて、昨日セーブしておいたＤＢを開きました。
９．なんと！、昨日セーブしてあったＤＢを立ち上げ、あるフォームを実行したところ、また先ほどと同じコンパイルエラーが出ます！ＤＢが違うはずなのになぜ？？？
１０．ＡＣＣＥＳＳ経験者に応援を求め、とりあえず壊れたコマンドが表示されている画面の全ての行に「’」を入れてコメント行にしたところ、なんとかエラーは起きなくなりました。
以後どのＤＢ、どのフォームを開いても大丈夫です。

以上が経緯ですが、こんなことってＡＣＣＥＳＳではありえることなのでしょうか？
とりわけ、あるＤＢの不具合が全く別のＤＢにも波及するというのは全く理解できませんしこんなことではＡＣＣＥＳＳをこれから使う気も失せてしまいそうです。

何かアドバイス等あればよろしくお願いいたします。

回答No.3

gadd3 · ベストアンサー

>sirouto012 さん

私の書き方が悪くて不快な思いをさせてしまったとしたらごめんなさい。
謝ります。

>やはり、今回の現象は私のACCESSの知識・経験不足ということでしょうか？

私は２０００から使い始めて、今でも２０００を使っています。

初代のAccessを使っていたり、RDBのプロの方からすれば
ひよっこもいいとこで、まだまだ修行中ですが、それでもまず言えるのは、
Accessは、ExcelやAPIなどと連携させて使えば
「セキュリティを必要としない小規模RDB」を構築する場合、
本当に役に立つソフトだということです。
少なくとも、ある一定規模・条件の下でのRDBとしては、
どんな無料RDBよりも効率が良いと考えています。
（堅牢・高機能とは口がさけてもいえません。
　しかし、堅牢・高機能さ、価格と、効率の良さは必ずしも比例しません。
　特に、中小・零細の現場では。）

しかし、少し高度なこと（クライアントサーバ的なシステム構築）を
する場合は、Accessはやはり裏セオリーを知らないと（正直）使いづらいです。

裏セオリーとは、今回のこのご質問の回答において私が勝手に作った
言葉です。

例えば、Access2000の場合有名な裏セオリーとしては、
Win2000以上のOSでクライアントサーバ的にシステムを組む場合です。
ファイルサーバにテーブル専用のmdbだけを置き、クライアントから
そのmdbを覗きに行く場合です。

リンクテーブルを使うことになりますが、２台目のクライアントの
接続から、動作速度が低下することがあります。
その場合は
「あらかじめ、サーバ側のmdbにダミーテーブルを作っておき、
　それをソースにフォームを作り、AutoExecなどで非表示オープンしておくと
　リンクテーブルを扱うときにパフォーマンスが低下しない」
などの裏セオリーがあります。
フォームを作らないなら、クライアントmdb起動時に、
DAOでリンクテーブルを先に開いておいても同じです。
また、サブデータシート機能をVBAにてOFFにしておくとか
並べ替えのデフォONをVBAにてOFFにしておくとか、
そういったことです。
（他にも色々とありますが。）（OSがWin98なら必要ない）
それにより、
・テーブル操作
・テーブルをソースにしているオブジェクトデザイン
・クエリ操作、クエリパフォーマンス
などで、本来の速度よりも低下させないで作業ができます。
実行速度も結構速いです。
ローカルでならSQLSeverとそれほど代わらない気がします。

そのほか、インデックスがきちんと使われてクエリが実行されているかを
調べる関数（ShowPlan関数）を使えるようにレジストリ設定するとか、
OSがWin2000以上で、もしクライアントサーバもどきの形態で破損が多いなら、
OpLockのレジストリ設定で破損しないようにするとか、色々とあります。
（OSがWin98なら必要ない）
あとセオリーではないですが、Rushmore、など、９７からの技術のこと、など。

すべて、マイクロソフトの技術情報に書いてあります。

名前の自動修正機能はオプションメニューから設定します。
これのOFFは裏セオリーかどうかはしりませんが、
自動修正機能がらみの有名な不具合は、
「レポートの余白設定がレポートを開くたびに初期設定に戻ってしまう不具合」
です。
Access2000SR-1で修正されているはずが、なぜが不具合が起こったり。
それ以外の不具合にも影響しているようで、
マイクロソフトのKBにも「こいつが原因だからOFFにして」と
ちょくちょく出てきます。
私はオブジェクト（クエリなど）のデザイン時の処理速度が
遅くなったりすることもあるし、意味不明のエラーの原因だった
ことが経験上、多かったので絶対に使いません。

ちなみに、インストールもバージョンを混ぜたりすると
いらん不具合を起こすことがあるのでしないようにしてます。
またSPは必ずあてます。

以上のようなことを知らないと、「ベース部分」をどのように作ったら
トラブルが少ないか、とか、高速動作させられるか、がわからないです。
「ベース部分」を作るのに必要な知識なので、
だから私は勝手に「裏セオリー」と前回の回答に書きました。

>おっしゃるような「裏セオリー」というのは何かに載っているのでしょうか？
前述のとおり、私が勝手に書いた言葉ですのでどこにも載っていません。
でもマイクロソフトの技術情報をちゃんと読んでいるか、
ヘンなエラーにいつも「してやられて」、解決策をWeb検索しまくっていれば
かならず見つかる情報ばかりです。

>VBAをコメントにしたら直ったところからすると
>DLL破損等ではない様に思いますがどうでしょうか？
>それにも拘らず別のDBに影響したということが不思議でなりません。

私も不思議です。「別のDBに影響」なんてことがあるのか？と思いました。

でも、その前にエラーがたくさん出たということでしたので、
「別のDBに影響」なんてことがもしあるとすれば、DLLの破損くらいしか
考えられないかなあ？とおもいました。
もしくは、「そう見えてるだけ」で内部的に違うとか。

いずれにしても、本当に「別のDBに影響」しているのかどうか自体も
実際にsirouto012 さんが作ったmdbを細かいところまで、見てみないと
なんともいえないので「推測」ということで書かせていただきました。
コメントアウトしてもしなくても、「別のDBに影響」ということなら
Accesss本体やDLLが破損していれば、可能性はゼロじゃないと考えたものですから…。
砂時計が出て30分固まったときに何か起こったのかな？と考えたのです。
もちろんご質問にはエラーメッセージも何もご提示されてなかったので
これも推測にすぎません。すみません。

>「名前の自動修正機能」はどこで設定するようないなっていたのでしょうか？

前述のとおりです。また、Webで検索すれば出てきます。

>しかし確かに私のACCESSに対する印象としても、
>いろんなところでユーザーの補助というか、
>自動的にいろんな名前や何かを設定してくれたり、
>いろんなころを裏でやってくれるのですが、

まさに、Wordのデフォ設定とおなじ
「おせっかい機能」、という感じです。
そのせいでいろんなトラブルが・・・。
マイクロソフト製品はOSも含め、デフォ設定で使うな！・・・みたいな。

>全体が理解できていない私のような初心者にとってはいいような悪いような・・・。

私はマイクロソフト製品の悪いところのような気がしています。

>「いろんなエラー」と書きましたが、
>自動で設定された名称を自分にわかりやすいよう修正する中で
>何度もエラーが出たというよう>なことで、
>「無茶な操作」と書かれているのが
>「高度なテクニックを駆使した操作」だとすれば、まったく違います。
>また、「カッコとか半角カタカナ」を名称に使用するようなこともしておりません。

ということでしたら、
普通であればmdbが破損したり、
「別のDBに影響」なんてことはあるはずがない気がします。

それでも頻発するなら、
もしかしたらアンチウィルスソフトなど、裏で動いているサービスの
影響かもしれないですね。ただその確率もかなり低そうですが…。
もしくはたまたま運が悪かったのか…。

VBEditor（VBE）がらみの不具合かもしれないですけど・・・。
VBEの本体のDLL（VBE×.dll）を入れ替えたら治るとか・・・。
（また推測ですみません）

>>ＡＣＣＥＳＳの場合はすぐに壊れるという話」をする人のほとんどが
>>「どうしたら破損するか/しないか」のテストすらしたことがなく、
>>単純に自分の技術が未熟なだけなので、これは完全に誤りです。

>おしえて頂きながら言葉を返すようで申し訳ないのですが

とんでもございません。

>ユーザーが「どうしたら破損するか/しないか、のテスト」をしてしか
>使えないようなソフトだとしたら、
>一般の企業ユーザーが使えるようなソフトではなく
>特殊なマニア向けソフトというになるのではないのでしょうか？
>少なくとも（私が知らないだけかもしれませんが）
>単にエラーになるというだけでなくDBが破損するという
>重大事項に関することなのですから
>MSが禁止事項等として注意を喚起してくれるのが普通だと思います。

まったくもっておっしゃるとおりだと思います。

私も、裏セオリーのことを「パッケージに書け！」
「CDケースに小冊子として入れろ」と言いたいです。
でもそうならない。
KBだけ発信してそれでよしとしているのだと思います。
マイクロソフトはユーザーをバカにしている気もします。
マイクロソフトはAccessを作ってくれたので大変感謝していますが
でも私はユーザーサポートの姿勢としては大嫌いな会社です。
2007でも機能後退していまったですし・・・。

>一般の企業ユーザーが使えるようなソフトではなく

「だからプロしか使わないで」、とでもいいたげなソフトです。
Accessは。
Accessがダメというより、マイクロソフトのアフターの姿勢が
ダメすぎるという気もしないでもありません。

>単にエラーになるというだけでなくDBが破損するという
>重大事項に関することなのですから

Oplockのレジストリ設定などはその最たるものだと思います。
初めて知ったときは「最初に言ってくれえ～」と
叫んでしまいまいした（＾＾）

>ACCESS初心者といいながらすでに２・３ヶ月悪戦苦闘をしています。
>企業内の業務処理ということで、先々他の人に引き継ぐことも出てくると思いますが、
>これまでのことだけでも経験のない後継者に
>簡単に引き継ぐのは難しいと感じているのに加えて、
>マニアックな努力まで傾注しないと無理となると・・・

>しかしここまで来たので「これからもがんばってAccessを活用し」たいとは思いつつ、
>その辺もあって「ＡＣＣＥＳＳをこれから使う気も失せてしまいそう」な
>気分になっているのです。

おしゃりたいことは本当に良くわかります。
私も同じ理由で、なんどマイクロソフトとAccessに煮え湯を
飲まされたことか…。

しかし、
かといってファイルメーカを使う気にはなれません。
ファイルメーカも面白くて興味の沸くDBです。
使ってみたいですし、試用版では桐もファイルメーカも面白かったです。
「こんな機能がAccessにもあればいいのに」という感じで。
が、SQL使えなくて不便だし、Excelと連携しにくいし・・・。
一応、COMオートメーションに対応してたと思うので、
やれないことはないと思いますが、
AccessからExcelのイベントプロシージャを直接Callしたり
その逆をしたり、mdb同士でやったり、・・・。
そういったことがエラー無くできるか不安です。

MYSQL（SQL Server等）＋PHP？
HTMLタグとかの引継ぎもするの？って感じです。
AccessならDAPでASPがウィザードで作成できてしまいます。
しかも、ブラウザインタフェイスで動作が遅い。
いらいらします。
一覧表示もしにくい。
サブフォームが作りにくい、Excel連携もしにくい、
うっとおしいです。
（私の設計力の無さも原因かもしれませんが）

帳票フォームを作ってちょっとコード足すだけで
1つのフォームを、帳票、単票、データシート、フィルタ、と色々に
瞬時に切り替えて使い回せるAccessの便利さにはほど遠いです。

Accessも「なんだかな～」、ですけど、引継ぎを考えると
他のRDBも「効率が良いわけじゃない」と思います。
メリットデメリットを勘案して、
「トータル効率だけに注目すると」似たり寄ったりかな、と・・・。
（社員全員が、HTMLタグやPHPなどが得意な会社ならわかりませんが）

OooのBaseも遅いし。機能がAccessにとても及びません。

結局、Accessを使うしかないのでAccessを使っています。

クライアントサーバ的な感じで使う場合だけだと思います。
スタンドアロンならまず問題ないと思います。

>マニアックな努力まで傾注しないと無理となると・・・

裏セオリーは知っているか知らないかだけでして
操作自体は特に難しくありません。
でも、確かに不安ですよね・・・。

>ご親切に書いていただいているのにも拘らず、
>ついつい反論めいたことを書いてしまいましたが、

とんでもないです。
私の回答の書き方が悪かったのです。
すみません。意見交換おおいに結構だと思います。

>今はこれからどうしようかと途方にくれているような状況です。
>何かアドバイス

私は（少しだけですけど）、
「くそーAccessなんかに負けるか!マイクロソフトなんかに負けるか！」
「腹立つ！」、
「最初に言ってくれよ！」、
「かならずねじふせてやる」、
みたいな考え方でもこれまでやってきました。
Access（というかマイクロソフト）と付き合うには
そういう気持ちも多少は必要かもしれません。
あれほどユーザーのためにといいながら
ユーザーの気持ちを踏みにじる会社も無いかもしれません。

でもそうは思うものの、Accessが大好きです。

それもこれもAccessはExcelやAPIと連携すると
本当に便利だからです。

だから他のソフトにも浮気しないで使ってきました。

そもそも、コンピュータは人間が歩み寄らないと
何にもできないダメ機械、と私は認識しています。

腹を立ててもいいので、逃げないことしか、Accessとは
付き合えないかなあ、と少し、思います。

補足

gadd3さん

お礼が遅くなってしまって申し訳ありません。
非常に丁寧なアドバイス本当にありがとうございました。

＞私の書き方が悪くて不快な思いをさせてしまったとしたらごめんなさい。謝ります。

とんでもありません。
せっかく親切に教えていただきながら私がつまらないことを書いたせいでこちらこそ不快な思いをさせてしまって全く申し訳ありませんでした。

今回頂いたコメントで、gadd3さんのＡＣＣＥＳＳに対する思い、その良さを非常に評価されこれまで苦労されながらもいろんな努力・工夫をされて使いこなしてこられたのか、しかもそれ故にＭＳのサポートの対する姿勢にも疑問を感じられているということ。本当によく分かりました。
おっしゃるように

＞まさに、Wordのデフォ設定とおなじ「おせっかい機能」、という感じです。そのせいでいろんなトラブルが・・・。

私もＷｏｒｄについては「また小さな親切、大きなお世話だ」とぶつぶつ言いながら使わされています。
しかしＷｏｒｄについては（私の想像ですが）通常のＰＣユーザーがテキストエディターに毛の生えた程度の機能しか要らないと感じているのにもかかわらず、「ＭＳＷｏｒｄはこんなにも高機能なのですよ。もっともっと高度に利用してちょうだい！」
というようなＭＳの戦略上の都合で、そうしているのではないかと感じています。

そういう戦略があったたのかどうなのか分かりませんがＥＸＣＥＬと共にＯｆｆｉｃｅがデファクトになってしまったので、いやでも使わざるを得ないのが現状だろうと思っていますが、ＡＣＣＥＳＳについてそういうやり方はどうなんでしょうか？

複雑な裏の処理を隠蔽（？）して「非常に易しくてしかも結構高機能なことができるデータベースソフト」として売り出した？つまり
スタートは「誰でも簡単に使えるので素人が使っても大丈夫なソフト」だった？

そういう作りになっていながら、それ以降の他社製品との競合の中でどんどん機能拡張をしたせいで（私の想像）

＞「だからプロしか使わないで」、とでもいいたげなソフトです。Accessは。

という風になってしまった？

私の勝手な想像ではそんな感じです。

易しくするなら高度で複雑な機能はないけれども、誰でも全体がすぐに理解できて安心して使えるソフト。複雑なところは隠蔽して触れないようにしてトラブルを防ぐ。

あるいは

あらゆる高度な要求に答え得るプロ用のソフト。素人には敷居が高いソフトですよとはじめからわからせる。妙に丁寧に自動でいろんなパラメータを自動設定したりせず必要なら自分で記述させる。それによって構造もシンプルにする。

どっちかだと思うのですが・・・
両方を１つのＡＣＣＥＳＳというもので満たそうというところに無理があるような・・・

ごめんなさい。
また、自分の努力不足を棚に上げて勝手なぼやきになってしまいました。

とりあえず、お教えいただいた「名前の自動修正機能」についてはＯＦＦに設定しました。

＞腹を立ててもいいので、逃げないことしか、Accessとは付き合えないかなあ、と少し、思います。

よく分かりました。ありがとうございます。もう少し頑張ってみようと思います。
gadd3さんのレベルまで行くのはとても無理と思いますが頂いたアドバイスとgadd3さんのＡＣＣＥＳＳに対する思いで元気付けられました。

これからもどうかよろしくご指導のほどお願い申し上げます。

回答No.2

DexMachina

> 同じＤＢ内の全く別のフォームを実行してもコンパイルエラーが出ます。

Accessでは(Excelなどの他のMS Officeでも同様かもしれませんが)、
VBAを実行させる度に、「今起動させようとしているコード」だけでなく
全体が見渡されます。
(データベース全体で共通(Public)なユーザー関数などを使用するには
　そうせざるを得ません)

そのため、開こうとしたのとは別のフォームでの文法上のエラーなどで
あっても、ご質問の件のようにコンパイルエラーが発生します。
(全ての文法エラーが対象になるわけではないようですが、今回のように
　「Private Sub ○○」の「Private」が「ate」になったような状態だと、
　実行しようとしたコードの位置に関係なく対象になるようです)

これを回避するため、私の場合は、VBAの編集時には手動でこまめに
コンパイルを実行するようにしています。
(VBE画面のメニューで、「デバッグ(D)→○○のコンパイル(L)」を選択：
　全体のコンパイルが終了すると選択不可・グレー表示になりますが、
　再度VBAの編集を行う(=コンパイル未了の状態にする)と使用可能に
　なります)

> 昨日セーブしてあったＤＢを立ち上げ、あるフォームを実行したところ、
> また先ほどと同じコンパイルエラーが出ます！

この「他のDB」が全くの別物なら、No.1の方の回答にあるようにDLLの
破損などを考える必要がありますが、今回は「前日保存したバックアップ」
ということを考えると、そのとき既に、「Private」が「ate」に書き換えられて
しまっていた、と推測されます。
(VBA起動時には上記コンパイルエラーが発生するものの、VBAに直接
　関係しないクエリの実行などであれば上記問題が顕在化しないため、
　気づかれなかった、ということではないでしょうか・・・?)

私自身、データベースの破損はあまり経験がありません。
(職場で数人で共有しているDBで、テーブルとそれ以外に分割した後は、
　確か一度もなし：
　Accessが落ちることはそこそこの頻度でありますが(汗))

とはいえ、初心者のうちは、発生した不具合がバグなのかプログラムミス
なのかで悩むことも多いかと思いますので、
　・(共有時は)テーブルとそれ以外の分割
　・こまめなバックアップ
　・こまめなコンパイル
をお勧めします。
(あと、人によっては勧めないと言われますが、私としてはAccess画面の
　「ツール(T)→オプション(O)」で『オプション』ダイアログを開き、『全般』タブ
　の「閉じる時に最適化する(C)」のチェックをオンにすることをお勧めします)

補足

DexMachinaさん

ありがとうございます。

＞この「他のDB」が全くの別物なら、No.1の方の回答にあるようにDLLの破損などを考える必要がありますが、今回は「前日保存したバックアップ」ということを考えると、そのとき既に、「Private」が「ate」に書き換えられてしまっていた、と推測されます。(VBA起動時には上記コンパイルエラーが発生するものの、VBAに直接関係しないクエリの実行などであれば上記問題が顕在化しないため、気づかれなかった、ということではないでしょうか・・・?)

これは違うと思います。
まったく動かなくなり、やむを得ず強制終了したらすぐに今回の現象が発生したので、その前からということは考えられないと思います。
ただ、そのまえに知らず知らずのうちに遠因を作ってしまっていたということならありえるかもしれません。

手動コンパイルについてははじめて知りました。
今回のようにプログラムソースが壊れた（こんなこと自体あるというのが驚きでしたが）ことが明白な場合には、手動コンパイルも何もできようはずはないと思うのですが
それ以外の場合（通常の状態と思われる時）にも手動コンパイルをすれば、いろんなチェックをしてくれて大きなトラブルを未然に防いだり、いろんな指摘をしてくれたりするのでしょうか？

「閉じる時に最適化する(C)」については一度やってみようと思います。

申し遅れましたがACCESSは２００２です。

回答No.1

gadd3

>こんなことってＡＣＣＥＳＳではありえることなのでしょうか？

データベースのファイル構造やテーブル構造、その他、細かいことが
わからないのでなんともいえませんが、
例えばあまりにも無茶な作り方をしていたり、
Accessを使うときの裏セオリーというか、そういうことをあまりにも
知らないとか、知っていても無視し続けると、
ありえないことではないと思います。

>とりわけ、あるＤＢの不具合が全く別のＤＢにも波及するというのは
>全く理解できませんしこんなことではＡＣＣＥＳＳをこれから
>使う気も失せてしまいそうです。

繰り返しで申し訳ありませんが、ご質問の内容からは細かいことが
書いてないので何が原因かはわかりませんが、
「あるＤＢの不具合が全く別のＤＢにも波及する」というのは
滅多にあることでも無いですが、
システムの構造やファイルの取り扱いによってはありえないことではないと思います。
（例えば無茶な操作をしたので、AccessがらみのDLLファイルが破損してしまった、など。Accessの再インストールで治る、など）

Accessは裏セオリーが多いソフトといえばそうかもしれません。
マイクロソフトのKBをよく見ていればいいのですが・・・。
そうでないと扱いづらいかもしれません。
いずれにしても、Accessはすんなり行かないことが少なくないので
「あきらめない」ことが重要かと思います。
「裏セオリー」があること自体が「欠陥ソフト」といえなくもないのですが、マイクロソフトのKBを見ていれば、
「解決できる」、「破損しない」ことがほとんどです。
そして実際に、仕事で効率アップして経費を浮かせたり売上アップの
ヒントにもできます。
なので、結局「使う人の腕次第」、とうことになります。

>ＡＣＣＥＳＳの場合はすぐに壊れるという話を聞いていましたので
「>ＡＣＣＥＳＳの場合はすぐに壊れるという話」は、
確かによく聞くことですが、誤りです。
Accessの裏セオリー、連結・非連結、ループ処理などをきちんと把握、
理解して、「データベースの基礎」もふまえたうえで作成すれば
まず破損は起こりません。
私も結構無茶な作り方をしますが、破損なんてしません。

いずれにしても、破損させないようにも破損させるようにも作れます。
少なくとも、どうすれば破損しやすいか、確実に破損するか、は
知っています。
でも質問者さんのような現象での破損は一度もないです。
例えば
>２．一旦ウィザードでフォームを作った後、
>かなりあちこちをいじっておりました。
>いろいろなエラーメッセージが表示されていました。
>３．突然、砂時計が出っ放しになって
>どこをクリックしても受け付けられなくなりました。

ここから推測するなら、
名前の自動修正機能がONになっているとか。
あの機能はわかのわからんいろんな不具合を呼び起こし、
パフォーマンスも低下させるのでわたしは絶対に使いません。
あと、フィールドやオブジェクトの名前の付け方が悪くて
エラーを呼び起こすこともあります。
名づけに記号を使っていたりとか（特にカッコとか半角カタカナとか）

ただ、
>いろいろなエラーメッセージが表示されていました。
ということですので、
それが原因かどうかはわかりませんが・・・。
エラーメッセージは出たらすぐにメモしておくとよいと思います。
エラーメッセージが、他人が判断できる一番重要な情報ですので。
エラーメッセージがご提示されてない場合、結局まともな回答は得られません。

「>ＡＣＣＥＳＳの場合はすぐに壊れるという話」をする人のほとんどが
「どうしたら破損するか/しないか」のテストすらしたことがなく、
単純に自分の技術が未熟なだけなので、これは完全に誤りです。
信用してはいけないと思います。

厳しいようなことを書いてしまって申し訳ありませんが、
これからもがんばってAccessを活用してください。

補足

gadd3さん

遅くなりましたがまず、お礼を申し上げます。
やはり、今回の現象は私のACCESSの知識・経験不足ということでしょうか？
もう少しお教え頂けると有難いのですが

＞あまりにも無茶な作り方をしていたり、Accessを使うときの裏セオリーというか、そういうことをあまりにも知らないとか、知っていても無視し続ける・・・

まだ初心者で無茶というか高度な？ことはやろうにもできないというスキルのレベルだと思います。おっしゃるような「裏セオリー」というのは何かに載っているのでしょうか？

＞「あるＤＢの不具合が全く別のＤＢにも波及する」というのは滅多にあることでも無いですが、システムの構造やファイルの取り扱いによってはありえないことではないと思います。（例えば無茶な操作をしたので、AccessがらみのDLLファイルが破損してしまった、など。）

VBAをコメントにしたら直ったところからするとDLL破損等ではない様に思いますがどうでしょうか？それにも拘らず別のDBに影響したということが不思議でなりません。

＞名前の自動修正機能がONになっているとか。あの機能はわかのわからんいろんな不具合を呼び起こし、パフォーマンスも低下させるのでわたしは絶対に使いません。あと、フィールドやオブジェクトの名前の付け方が悪くてエラーを呼び起こすこともあります。名づけに記号を使っていたりとか（特にカッコとか半角カタカナとか）

「名前の自動修正機能」はどこで設定するようないなっていたのでしょうか？
今は会社ではないので休み明けに会社に出たら見てみようと思います。
しかし確かに私のACCESSに対する印象としても、いろんなところでユーザーの補助というか、自動的にいろんな名前や何かを設定してくれたり、いろんなころを裏でやってくれるのですが、全体が理解できていない私のような初心者にとってはいいような悪いような・・・
「いろんなエラー」と書きましたが、自動で設定された名称を自分にわかりやすいよう修正する中で何度もエラーが出たというようなことで、「無茶な操作」と書かれているのが「高度なテクニックを駆使した操作」だとすれば、まったく違います。
また、「カッコとか半角カタカナ」を名称に使用するようなこともしておりません。

＞ＡＣＣＥＳＳの場合はすぐに壊れるという話」をする人のほとんどが「どうしたら破損するか/しないか」のテストすらしたことがなく、単純に自分の技術が未熟なだけなので、これは完全に誤りです。

おしえて頂きながら言葉を返すようで申し訳ないのですが
ユーザーが「どうしたら破損するか/しないか、のテスト」をしてしか使えないようなソフトだとしたら、一般の企業ユーザーが使えるようなソフトではなく特殊なマニア向けソフトというになるのではないのでしょうか？
少なくとも（私が知らないだけかもしれませんが）単にエラーになるというだけでなくDBが破損するという重大事項に関することなのですからMSが禁止事項等として注意を喚起してくれるのが普通だと思います。

ACCESS初心者といいながらすでに２・３ヶ月悪戦苦闘をしています。
企業内の業務処理ということで、先々他の人に引き継ぐことも出てくると思いますが、これまでのことだけでも経験のない後継者に簡単に引き継ぐのは難しいと感じているのに加えて、マニアックな努力まで傾注しないと無理となると・・・

しかしここまで来たので「これからもがんばってAccessを活用し」たいとは思いつつ、その辺もあって「ＡＣＣＥＳＳをこれから使う気も失せてしまいそう」な気分になっているのです。

ご親切に書いていただいているのにも拘らず、ついつい反論めいたことを書いてしまいましたが、今はこれからどうしようかと途方にくれているような状況です。
どうかお許しいただき何かアドバイスがありましたらよろしくお願いします。