Access (VBA)

Access VBAに関するフォーラムです。
  • 解決済みのトピックにはコメントできません。
このトピックは解決済みです。
質問

 
(指定なし : Access 2010)
テーブルに書き込まれたタイミングが知りたい
投稿日時: 19/07/04 11:09:38
投稿者: 滝沢

Accessファイル自体は数十人が使用していますが、そのうち1人だけ使用するフォームAがあります。
このフォームAはデータを追加登録するフォームで、テーブルAに書き込まれます。
このテーブルAに、追加していないはずの謎のレコードがどんどん増えていきます。
 
どのような画面からとかオペレーションで追加されているのかを調べることは可能でしょうか?

回答
投稿日時: 19/07/04 11:46:29
投稿者: sk

引用:
このフォームAはデータを追加登録するフォームで、テーブルAに書き込まれます。
このテーブルAに、追加していないはずの謎のレコードがどんどん増えていきます。

・[フォームA]は[テーブルA]をレコードソースとする連結フォームなのか、
 それとも非連結フォームなのか。
 
・仮に[フォームA]が連結フォームであるとした場合、
 「データを追加登録するフォーム」というのは
 「[データ入力用]プロパティを「はい」に設定しているフォーム」
 ということなのか。それとも別の意味を表しているのか。
 
・逆に[フォームA]が非連結フォームであるとした場合、
 具体的に「データを追加登録する」機能を
 どのような形で実装したのか。
 (イベントマクロ/イベントプロシージャの内容)
 
・ここでいう「謎のレコード」とは具体的にどのような内容のものなのか。
 
引用:
どのような画面からとかオペレーションで追加されているのかを調べることは可能でしょうか?

「テーブルのデータシートビューからレコードが追加された」とか
「追加クエリによってレコードが追加された」といった操作まで
含めるのであれば「基本的には無理」という回答になります。
(限定的な情報であれば一応は可能だが、それには一定の条件がある)
 
[フォームA]に対する操作によってその現象の再現性が確認されているのであれば、
まずは[フォームA]自体のデザインや、実装した CRUD 機能の検証を行なうのが
筋でしょう。

回答
投稿日時: 19/07/04 12:06:20
投稿者: Suzu

地道に、一定時間ごとに件数がどうなっているか監視し
異常値が発生した際に、ファイルを実行している人、操作内容 を確認していくしかないのでは?
 
テーブルA のみ 別ファイルにし、
フォームA を操作する人だけに、リンクテーブルを持たせ
本当に、フォームA からの操作にて増えているのか確認するのが最初でしょうか。

回答
投稿日時: 19/07/04 13:50:27
投稿者: sk

Suzu さんの引用:
地道に、一定時間ごとに件数がどうなっているか監視

ただレコードの追加/更新/削除が発生した日時を知りたいだけなら、
[テーブルA]にデータマクロを仕込めば一応可能です。
 
引用:
(指定なし : Access 2010)

但しデータマクロを使用出来るのは、実行環境の Access のバージョンが
Access 2010 以降の環境であり、かつデータベースファイルの
ファイル保存形式が accdb ファイルである場合に限られます。
(実際のファイル保存形式が何であるかは現在不明)

投稿日時: 19/07/04 15:00:10
投稿者: 滝沢

sk さんの引用:
・ここでいう「謎のレコード」とは具体的にどのような内容のものなのか。

顧客cd 状況 備考 
000001 見積 見込み薄
000002 アポ 
000003 見積 最安値
000004 
 
000001〜000003はフォームAで登録したデータで、000004が謎のデータです。
フォームAで「状況」は「空白不可」にしているので、本来ありえないし
また今日もすでに30件も増えており、うっかりレベルでは無い件数です。
 
sk さんの引用:
・[フォームA]は[テーブルA]をレコードソースとする連結フォームなのか、
それとも非連結フォームなのか。
フォームAはテーブルAの連結フォームです。
実際は先に「非連結フォームB」を開き、値を入力して「登録ボタン」をクリックすると
フォームAを開く→Newレコードに進む→Bの値をAにわたす→AとBを閉じる。
という形です。
[データ入力用]プロパティは「いいえ」です。
(知りませんでした。これを「はい」にすれば「→Newレコードに進む」が要らないということですね)
 
sk さんの引用:
[テーブルA]にデータマクロを仕込めば一応可能です。
これも後ほど試してみます。
あと、フォームA(B)を開けないようにしてみます。

回答
投稿日時: 19/07/04 15:42:42
投稿者: sk

引用:
顧客cd 状況 備考 
000001 見積 見込み薄
000002 アポ 
000003 見積 最安値
000004 
  
000001〜000003はフォームAで登録したデータで、000004が謎のデータです。

[顧客cd]が[テーブルA]の主キーであるとして、
[顧客cd]以外の全てのフィールドの値が Null である、
という状況なのでしょうか。
 
引用:
フォームAで「状況」は「空白不可」にしているので、本来ありえないし
また今日もすでに30件も増えており、うっかりレベルでは無い件数です。

それは[テーブルA]側のフィールド[状況]の定義における
[値要求]プロパティ[空文字列の許可]プロパティの設定によって
Null 値(および空文字列)が格納されないようになっている、
という意味でしょうか。
 
それとも、フィールド定義側の設定は特に何もしていなくて
[非連結フォームB]側の設定やコードによって
[状況]に入力された値の評価を行なっている、
という意味でしょうか。
 
引用:
フォームAはテーブルAの連結フォームです。
実際は先に「非連結フォームB」を開き、値を入力して「登録ボタン」をクリックすると
フォームAを開く→Newレコードに進む→Bの値をAにわたす→AとBを閉じる。
という形です。
[データ入力用]プロパティは「いいえ」です。

今のところの印象としては、まずその仕組み自体に問題があると思います。
 
その一連の操作を[非連結フォームB]側のイベントプロシージャに
記述されたコードによって実行されているとして、例えば
「Bの値をAにわたす」部分の処理が、何らかの原因によって
全てのフィールドへの値の代入が完了しないまま中断され
(例えば[状況]への値の代入をしようとした際に実行時エラーが発生し)、
[顧客cd](主キー)への値の代入のみが行なわれた状態で
[フォームA]が閉じられてしまえば、当然上記のような状態で
[テーブルA]に新規レコードが保存されることになります。
 
仮に上記と同様の現象が発生しているとするならば、
その次に問題となるのは以下の 2 点です。
 
・[登録ボタン]の Click イベントの発生時に実行されるプロシージャにおいて、
 エラートラップが正しく行われているのか否か。
 
・レコード追加処理の途中で実行時エラーが発生した際に
 その追加処理を取り消す(アンドゥする)操作を加えているか否か。
 
いずれにしても、新規レコードを編集するためのインターフェースが
[フォームA]ではなく[非連結フォームB]であるならば、
より非連結フォームに適した「レコード追加処理」の仕組みを
構築された方がよいでしょう。
 
引用:
これも後ほど試してみます。

そういうわけですから、現時点では
「テーブルに書き込まれたタイミング」を
知ったところでどうにもならないと思います。

回答
投稿日時: 19/07/04 16:09:56
投稿者: Suzu

引用:
顧客cd 状況 備考 
000001 見積 見込み薄
000002 アポ 
000003 見積 最安値
000004 
 
000001〜000003はフォームAで登録したデータで、000004が謎のデータです。
フォームAで「状況」は「空白不可」にしているので、本来ありえないし
また今日もすでに30件も増えており、うっかりレベルでは無い件数です。
 
実際は先に「非連結フォームB」を開き、値を入力して「登録ボタン」をクリックすると
フォームAを開く→Newレコードに進む→Bの値をAにわたす→AとBを閉じる。
という形です。

 
テキストボックスの入力規則 等で 空白不可 としているのですよね。
それ、、空白不可 本当に フォームA ですか?フォームBでなく?
 
レコードが存在している以上、何か仕組みに問題がありそうですね。
 
 
「000004」これ、連番になっていますよね?
この連番の 次の値を取得する仕組みは、どの様になっていますか?
 
オートナンバーを 6桁 表示になる様、書式設定をしている?
それとも、連番を取得する仕組みがあるのでしょうか?
 
・オートナンバーであれば、単に、新規レコードに移動した後に、
  どこかのフィールド(またはフィールドに連結したコントロール)に値を代入していませんか?
 
・連番を取得する仕組みがあるなら、その連番をテキストボックスの値に代入していませんか?
  値に代入すると、その時点で、新規レコードが 入力され始めた と言う事になります。
  値ではなく、既定値に設定するのが常套手段です。
 
 
非連結フォームにて入力 → 連結フォーム のコントロールに代入 と言う処理は、
今回の分も含め、不安定な制御になりそうですので、お勧めしません。
 
 
引用:
[データ入力用]プロパティは「いいえ」です。

で驚いていらっしゃるのであれば、
 
非連結を使用した目的として、既存レコードを見られたくない なのではありませんか?
素直に、「データ入力用」を「はい」で運用しましょう。

投稿日時: 19/07/08 15:10:51
投稿者: 滝沢

sk様、Suzu様
いろいろとコメント・アドバイスありがとうございます。
 
先週 5日(金)からフォームA・Bを開けなくしましたが、データはどんどん増えていきます。
フォームA・Bにも問題はあるようですが、今回の件は別件のようですので
とりあえず本件を解決したら、A・Bも修正したいと思います。
 
ありがとうございます。

回答
投稿日時: 19/07/08 15:54:36
投稿者: sk

引用:
先週 5日(金)からフォームA・Bを開けなくしましたが、データはどんどん増えていきます。

ならばとりあえずは、[テーブルA]を何らかの形で参照している全てのオブジェクト
(テーブル/クエリ/フォーム/レポート/マクロ/モジュール)をしらみつぶしに
調査することになるでしょう。

投稿日時: 19/07/10 18:44:26
投稿者: 滝沢

sk さんの引用:
ならばとりあえずは、[テーブルA]を何らかの形で参照している全てのオブジェクト
(テーブル/クエリ/フォーム/レポート/マクロ/モジュール)をしらみつぶしに
調査することになるでしょう。

追加されてしまうオペレーションがわかったので調べたら、あるフォームのレコードソースに
なっているクエリに、意味もなくテーブルAがつながっていて余計な動きをしていました。
消したら直りました。
色々とありがとうございます。
 
よろしくお願い致します。