Access (一般機能)

Accessの一般機能に関するフォーラムです。
  • 掲示板への投稿には会員登録(無料)が必要です。会員登録がまだの方はこちら
  • 掲示板ご利用上のお願い」に反するご記入はご遠慮ください。
  • Q&A掲示板の使い方はこちらをご覧ください
トピックに返信
質問

 
(Windows 8 : Access 2007)
テーブルレコードの一部が消えてしまう
投稿日時: 19/04/23 21:56:01
投稿者: uni_corn_623

こんにちは。初めて投稿します。
宜しくお願いします。
 
Accessでテーブルに毎朝データをインポートしています。
インポートテーブル(A)を使ってテーブル作成クエリ(C)を毎朝実行してテーブル(B)を作成しています。
毎日件数は違いますが、実行後の件数はだいたい5000件台です。
5573件だったり、5764件だったり、毎日の誤差はその程度です。
そのAccessファイルは共有フォルダに置いてあり、複数の人が触ります。
(A)テーブルレコード削除クエリと(B)テーブルレコード削除クエリがクエリ一覧の中にありますが、滅多に触る人はいません。
もし間違えてダブルクリックしてしまっても本当に削除してよろしいですか?という
メッセージが出てくると思います。
そこで気づくと思いますし、実際、そのAccessファイルを触る人たちに聞いても
その削除クエリを触ってはいないということなんです。
テーブル作成クエリ(C)を間違えてダブルクリックしてしまってもメッセージが出ますので気づきます。
今まで3回あったのですが、そのテーブル作成クエリ(C)で作ったテーブル(B)のレコード件数がなぜか3000件ピッタリに減っていたことがあるのです。
先ほど申し上げたように毎日件数は違います。
でも必ず5000件台です。
3回とも3000件ピッタリに減っていたのです。
3回とも、朝、件数を見たときは間違いなく5000件台でした。
テーブル作成クエリ(C)を実行するのがだいたい9時くらい。
3000件になっていたのは3回とも時間はバラバラですが11時くらいだったり15時くらいだったり。
何をどうしたら3000件になるのかわからないのですが、クエリはそのテーブルの削除クエリ以外にも選択クエリがいくつかあります。
テーブル作成クエリは(C)1つだけです。
それ以外、追加クエリだったり更新クエリはありません。
なぜ毎回3000件なのか、なぜその件数に減ってしまうのか、本当に謎です。
同じようにテーブルのレコードが一部消失してしまうという経験をされた方、原因がわかる方はいらっしゃいますでしょうか。
返信、宜しくお願い致します。

回答
投稿日時: 19/04/24 10:04:21
投稿者: sk

引用:
Accessでテーブルに毎朝データをインポートしています。

・インポート元のファイル(もしくは外部データベースのテーブル)の形式と
 レコード件数が不明。
 
引用:
インポートテーブル(A)を使ってテーブル作成クエリ(C)を
毎朝実行してテーブル(B)を作成しています。
毎日件数は違いますが、実行後の件数はだいたい5000件台です。

引用:
今まで3回あったのですが、そのテーブル作成クエリ(C)で作った
テーブル(B)のレコード件数がなぜか3000件ピッタリに減っていたことが
あるのです。

・インポート処理が実行された直後の[テーブルA]のレコード件数が不明。
 
・[テーブル作成クエリC]の具体的な定義内容( SQL )が不明。
 
・具体的にどのような操作によって一連の処理を実行しているのかが不明。
 (マクロ、VBA など)
 
引用:
(A)テーブルレコード削除クエリと(B)テーブルレコード削除クエリ
クエリ一覧の中にありますが、滅多に触る人はいません。

・[テーブルBレコード削除クエリ]によって削除されるのが
 [テーブルB]の全てのレコードなのか、ある特定の条件に該当する
 一部のレコードなのかが不明。
 (もし前者なら、その削除クエリが実行された時点で
 [テーブルB]のレコード件数は 0 件になるはず。
 逆に後者なら、ある特定の条件に該当しないレコードが
 (たまたま) 3000 件である可能性がある)
 
引用:
Accessでテーブルに毎朝データをインポートしています。

引用:
インポートテーブル(A)を使ってテーブル作成クエリ(C)を
毎朝実行してテーブル(B)を作成しています。

引用:
3回とも、朝、件数を見たときは間違いなく5000件台でした。
テーブル作成クエリ(C)を実行するのがだいたい9時くらい。
3000件になっていたのは3回とも時間はバラバラですが11時くらいだったり15時くらいだったり。

引用:
テーブル作成クエリは(C)1つだけです。
それ以外、追加クエリだったり更新クエリはありません。

・[テーブルB]をレコードソースとする連結フォーム、
 [テーブルB]のレコードを編集する処理を実行するマクロ/モジュールが
 存在しているのか否かが不明。
 ([テーブル作成クエリC]とも[テーブルBレコード削除クエリ]とも
 全く関係のない操作/マクロ/コードによる現象である可能性がある)
 
引用:
そのAccessファイルは共有フォルダに置いてあり、複数の人が触ります
(A)テーブルレコード削除クエリと(B)テーブルレコード削除クエリが
クエリ一覧の中にありますが、滅多に触る人はいません
もし間違えてダブルクリックしてしまっても本当に削除してよろしいですか?という
メッセージが出てくると思います。
そこで気づくと思いますし、実際、そのAccessファイルを触る人たちに聞いても
その削除クエリを触ってはいないということなんです。

スイッチボードに当たるスタートアップフォームを作成せず、
誰でもナビゲーションウィンドウを操作できるようにしている
ということでしょうか。

投稿日時: 19/04/24 22:33:31
投稿者: uni_corn_623

返信ありがとうございます。
説明不足で申し訳ありません。
下記回答させていただきます。
(引用の仕方がイマイチよくわからずこのような形の回答でお許しください)
 
 
■インポート元のファイル(もしくは外部データベースのテーブル)の形式とレコード件数
⇒textファイルで件数は日々変わりますが約10万件です
 
 
■インポート処理が実行された直後の[テーブルA]のレコード件数
⇒上記のtextファイルをそのままインポートしているので元ファイルと同じ約10万件です
 
 
■[テーブル作成クエリC]の具体的な定義内容( SQL )
⇒[テーブルA]から特定のIDを抜粋しているだけです(IDが数字から始まっているのですが9から始まっているものだけを抜粋していて、フィールド数・フィールドの並び順などは[テーブルA]と[テーブルB]は全く同じです)
 
 
■具体的にどのような操作によって一連の処理を実行しているのかが不明
⇒フォームの中にボタンを作っていて、そのボタンをクリックすると選択クエリがエクスポートされるというVBAで動かしています
最初の[テーブルA]へのインポートだけは訳あって手動です、その後、テーブル作成クエリ[C]実行・[テーブルA]のレコード削除クエリ実行・[テーブルB]から必要なフィールドだけを抜粋した選択クエリをエクスポートしているVBAです
 
 
■[テーブルBレコード削除クエリ]によって削除されるのが
 [テーブルB]の全てのレコードなのか、ある特定の条件に該当する一部のレコードなのか
⇒[テーブルA]レコード削除クエリも[テーブルB]レコード削除クエリも全てのレコードを削除するクエリです
 
 
■[テーブルB]をレコードソースとする連結フォーム、
 [テーブルB]のレコードを編集する処理を実行するマクロ/モジュールが存在しているのか否か
⇒連結フォームはありません、レコードを編集する処理もしていません
 
 
■スイッチボードに当たるスタートアップフォームを作成せず、誰でもナビゲーションウィンドウを操作できるようにしているということでしょうか
⇒スタートアップフォームは設定しています、先ほど書いたボタンがあるフォームです
誰でもナビゲーションウィンドウを操作できるようにしています
特に非表示にはしていません
ただAccessを触る人全員に聞いてもナビゲーションウィンドウを直接触っている人はいないのです
スタートアップフォームで設定しているフォームの中のボタンしか触っていないのです
 
 
もしかしたら強制終了した場合に何かしらでテーブルからレコードが一部消失することがあったりするのでしょうか?
もしくはAccess終了に20秒くらいかかるのですが、それを待ちきれない人がたまにいましてDatabaseという名前のファイルが残ってしまっていたりすることがあります。
それが関係していたりするのでしょうか?
よくわかっておらず申し訳ありません。
ご教示宜しくお願い致します。

回答
投稿日時: 19/04/25 10:44:29
投稿者: sk

引用:
引用の仕方がイマイチよくわからずこのような形の回答でお許しください

Q&A 回答方法:
https://www.moug.net/faq/info_a.html#a2_3
 
引用:
■[テーブル作成クエリC]の具体的な定義内容( SQL )
⇒[テーブルA]から特定のIDを抜粋しているだけです

引用:
フォームの中にボタンを作っていて、そのボタンをクリックすると選択クエリがエクスポートされるというVBAで動かしています

引用:
連結フォームはありません、レコードを編集する処理もしていません

引用:
スタートアップフォームは設定しています、先ほど書いたボタンがあるフォームです

つまり、一種のファイルコンバートツールとして
使用されているということでしょうか。
 
引用:
■インポート元のファイル(もしくは外部データベースのテーブル)の形式とレコード件数
⇒textファイルで件数は日々変わりますが約10万件です

引用:
最初の[テーブルA]へのインポートだけは訳あって手動

引用:
その後、テーブル作成クエリ[C]実行・[テーブルA]のレコード削除クエリ実行・[テーブルB]から必要なフィールドだけを抜粋した選択クエリをエクスポートしているVBA

引用:
[テーブルA]レコード削除クエリも[テーブルB]レコード削除クエリも全てのレコードを削除するクエリ

「任意のテキストファイルを[テーブルA]にインポートし、
スタートアップフォーム上のコマンドボタンをクリックして
VBA のコードを実行」というところまでが 1 セットの作業になっているとして
(毎回[テーブルAのレコード削除クエリ]を実行しているなら、
テキストファイルのインポートも毎回行なわなければならないはず)、
その一連の操作の結果、エクスポートされたファイル(形式不明)の
レコード件数が 3000 件になってしまう([テーブルA]のうち、
[ID]の値が 9 から始まっているレコードの件数より少なくなる)ことがある、
ということでしょうか。
 
引用:
もしかしたら強制終了した場合に何かしらでテーブルから
レコードが一部消失することがあったりするのでしょうか?

データベースファイルを開いたまま Access を強制終了させるのは
ファイル破損の原因となり得ますので、極力避けた方が良いです。
 
引用:
もしくはAccess終了に20秒くらいかかるのですが、それを待ちきれない人が
たまにいましてDatabaseという名前のファイルが残ってしまっていたり
することがあります。

そのデータベースファイルの[閉じるときに最適化する]オプションが
有効になっているからでしょう。
(約10万件のテキストファイルをインポートしていれば、
肥大化したファイルの最適化と修復に時間が掛かるのは当然の結果)
 
引用:
そのAccessファイルは共有フォルダに置いてあり、複数の人が触ります。

ここまで公開していただいた情報から判断した限りでは、
[テーブルA]や[テーブルB]のデータを複数のユーザー間で
共有する必要性はないのではないかと思います。
(バックエンドデータベースとフロントエンドデータベースに
分割されているわけでもなさそうですし)
 
例えば、それぞれのクライアントのローカルドライブ上のフォルダに
そのデータベースファイルをコピー(配布)して、そのファイルを
使用してもらうようにした方が多少は動作が安定するはず。

回答
投稿日時: 19/04/25 10:56:48
投稿者: Suzu

直接の原因は判りません。。
レコードが抽出されているとかではないのですよね?
なんとなく、ユーザーの操作ではなさそうな気はしますが。。
 
 
10万件のレコードのインポートを毎日行っているのですよね。
その場合、ファイルサイズ、テーブルサイズはどうなっていますでしょうか。
【Access の仕様】
https://support.office.com/ja-jp/article/access-%E3%81%AE%E4%BB%95%E6%A7%98-0cf3c66f-9cf2-4e32-9568-98c1025bb47c
 
仕様に引っかかりませんか?
 
上記を防ぐ為に、

引用:
Access終了に20秒くらいかかるのですが

から察するに、「終了時最適化」にチェックが入っているのではありませんか?
 
 
【Access 2002 以降の破損したデータベースをトラブルシューティングおよび修復する方法】
https://support.microsoft.com/ja-jp/help/283849/how-to-troubleshoot-and-to-repair-a-damaged-access-2002-or-later-datab
 
引用:
マルチユーザー環境で 365 日 24 時間稼動するデータベース システムが必要な場合は、マイクロソフトではクライアント/サーバー型のデータベース システム (永続的なトランザクションをサポートする Microsoft SQL Server などのデータベース システム) の利用を推奨しています。

 
とあります。
 
いくつか改善案を。。
1.経験的に、オブジェクトの作成/削除(テーブル作成クエリ)はファイルに大きな負担。
  破損の原因になります。
  レコード削除クエリ/追加クエリ の組み合わせに替える。
 
2.ファイルをテーブルとそれ以外に分け、テーブルをサーバーに置き、
  クライアントにそのファイルへのリンクテーブルを及びその他のオブジェクト持ったファイルを配布
  (この段階で必要のない人には、追加/削除クエリを入れないや、
   パスワード画面を作り使用制限を掛ける等、間違って触り実行してしまうリスクを減らす)
 
3.上記の方法の時、テーブルを1テーブル1ファイルにし、ファイル容量を落とす。
 
4.上記の方法の時、終了時最適化を止め、サーバーのタスクスケジュラー等で、
  CompactDatabseメソッドにて、ファイル最適化及びバックアップを行うVBS等を起動させるようにする。
 
5.これは実際に動作/速度テストを行う必要がありますが、
  テキストファイル自体をインポートせずに、直接 Bテーブルにレコードを追加する
    (ファイル自体の容量が増えるのを防ぐ。ただし処理速度が遅くなる可能性あり
     テキストファイルのインポート、追加クエリ発行、削除クエリ発行までと速度比較必要)
 
   方法として二つの方法があります。
   ・テキストファイルをリンクテーブルとしてリンクさせ、追加クエリ作成
   ・追加クエリのSQLの FROM句にINを使用
       上記には、schema.ini を設定しておいた方が良いです
        http://makoto-watanabe.main.jp/access/acconAboutSpecsSchemaFiles.htm

投稿日時: 19/04/25 20:12:36
投稿者: uni_corn_623

skさん、Suzuさん、返信ありがとうございます。
 
説明がわかりづらく申し訳ありません。
もう一度、説明不足だった部分も含めて改めて書きます。
 
1.毎朝、textファイル(約10万件)を[テーブルA]にインポートしています。
 事情があってリンクは不可です。
 textファイルの内容が毎日変わるので毎朝インポートしています。
 
〜ここからVBAです〜
2.[テーブルA]からIDが9から始まるものだけを抜粋するテーブル作成クエリを実行して[テーブルB](約5000件)を作っています。
 
3.[テーブルB]を使った選択クエリで必要な項目だけを抽出したり、[作業日]というフィールドの日付をbetween〜andで条件をつけたりして抜粋したものをエクスポートしています。
 
4.最後に[テーブルA]のレコードを全て削除する削除クエリを実行します。
 
◆フォームは一つだけです。そのフォームの中にボタンがいくつかあります。
 全て選択クエリをエクスポートするためです。
 全ての選択クエリは[テーブルB]からデータを抜粋するためのものです。
 
◆終了時最適化にチェックを入れています。
 
◆終了時は毎回[テーブルA]はレコード0件、[テーブルB]は約5000件です。
 その状態でファイルサイズは約8000KBです。終了に20秒ほどかかります。
 終了時、最適化している間にDatabaseという名前のファイルが出現して完全に終了するとそのファイルは消えます。
 おそらくそのファイルが残っている時は誰かが強制終了した時だと思います。
 複数の人が触るので何度も強制終了はなるべくしないでください、もしした場合には再度Accessを開いて正常終了をしてくださいと伝えていますが、OAスキルのない人達が触っているので強制終了してしまう人が毎日
ではないですが1週間に2回くらいはあると思います。
 
◆今までに3回、[テーブルB]のレコード件数が約5000件から3000件ピッタリになっていることがありました。
 なぜ気づいたかというとエクスポートしたデータの件数がおかしいと気付き、[テーブルB]を開いてみたら3000件になっていたというものです。
 
◆作業しているのは同じ会社の人達です。その中で私が一番Accessに詳しいというだけで管理者のようになっています。
 
◆それぞれのローカルにコピーしてから作業するというのは確かにリスクを軽減できると思いますが、おそらくみんな面倒だからやりたくないとか、忘れてそのまま共有フォルダのアクセスを触ってしまうが必ず出てきてしまうので徹底するのが難しいです。
 
◆全員が全員同じ作業をするわけではなく担当制になっていますのでフォームの中のAボタンを触る人触らない人がいます。ですので、Aボタンを触る人にはAボタンが入ったAccessファイルだけ渡すというのはリスク回避できそうですが、(エクスポートデータのレイアウトを変えたいなどの理由で)VBAの修正がちょいちょい入るため、1つのファイルで管理したいという私のワガママで管理しているのが現状です。そしてボタンの数が全部で15個くらいあるので分けるのが大変ということもあります。
 
 
以上です。
 
 
終了時最適化はあまり良くないのでしょうか?
毎日、複数の人が何度もAccessを開いて作業して閉じているのでどんどんファイルサイズが大きくなるような気がします。
すみません、「サーバーのタスクスケジュラー等で、CompactDatabseメソッドにて、ファイル最適化及びバックアップを行うVBS等を起動させるようにする」の意味があまりよくわかりません。どこかにやり方が記載されているサイトなどありますでしょうか?
あと、テーブル作成クエリはあまりよくないのでしょうか?
やっぱり負担が重いでしょうか?
追加クエリの方が良いですか?
でも考えてみれば、テーブル作成クエリを使っているので、[テーブルB]のレコード削除クエリの必要性が今はあまりないですよね。
 
色々考えた結果、なぜ3000件になってしまうのかというところはよくわかりませんが、追加クエリにするのが良さそうですね。

回答
投稿日時: 19/04/26 11:01:41
投稿者: sk

引用:
1.毎朝、textファイル(約10万件)を[テーブルA]にインポートしています。
 事情があってリンクは不可です。
 textファイルの内容が毎日変わるので毎朝インポートしています。
  
〜ここからVBAです〜
2.[テーブルA]からIDが9から始まるものだけを抜粋するテーブル作成クエリを実行して[テーブルB](約5000件)を作っています。
  
3.[テーブルB]を使った選択クエリで必要な項目だけを抽出したり、[作業日]というフィールドの日付をbetween〜andで条件をつけたりして抜粋したものをエクスポートしています。
  
4.最後に[テーブルA]のレコードを全て削除する削除クエリを実行します。

1 から 4 までの操作を 1 日 1 回だけ(毎朝 9 時頃に)
実行しているということでしょうか。
 
引用:
◆終了時最適化にチェックを入れています。
  
◆終了時は毎回[テーブルA]はレコード0件、[テーブルB]は約5000件です。

ならデータベースの最適化も操作 4 を終えた直後に、
1 日 1 回だけ実行されるようにした方がよいと思います。
(と同時に、データベースのバックアップを行なうことをお奨めします)
 
引用:
終了時最適化はあまり良くないのでしょうか?

Access におけるデータベースの最適化とは、カレントデータベースと
同じフォルダに空のデータベースファイルを新規作成し、前者に含まれる
オブジェクト/レコードを後者に移し(その過程でデータの隙間を詰め)、
カレントデータベースを削除してから新規データベースの
ファイル名をリネームする、という流れによって実現されています。
 
したがって、複数のユーザーが同時にそのデータベースに
アクセスしている状態では、データベースの最適化を
実行することは出来ません。
 
また、[閉じるときに最適化する]オプションが有効になっている
データベースに関しては、一部の実行環境において
「最適化の際にエラーが発生する」とか
「データベースファイルが消失する」といった現象が
過去にも報告されています。
 
引用:
終了時、最適化している間にDatabaseという名前のファイルが出現して
完全に終了するとそのファイルは消えます。
おそらくそのファイルが残っている時は誰かが強制終了した時だと思います。

これに関しては、何らかの問題によって
データベースの最適化に失敗した場合も含まれます。
 
共有フォルダ内のデータベースファイルを最適化するには、
それを実行するユーザーに対してその共有フォルダに対する
アクセス権限が適切に付与されていなければなりません。
(例えばファイルを削除する権限が与えていなければ、
カレントデータベースを削除することは出来ない)
 
引用:
あと、テーブル作成クエリはあまりよくないのでしょうか?

テーブル作成クエリについては、既存のテーブル(この場合は[テーブルB])と
同じ名前のテーブルを作成しようとすれば、その既存テーブルをオブジェクト
(テーブル定義)ごと削除( DELETE ではなく DROP )してから
同名のテーブル(の定義とレコード)を新規作成するという流れになります。
 
もしテーブル作成クエリを実行しようとした際に(他のユーザーが)
その既存のテーブルに開いていた場合、テーブル作成クエリを
実行することは出来ません。
 
そもそも、複数のユーザーが常時共有する前提となっている、
いわゆるマスターテーブルを定義ごと削除するのは
データベースの運用上において御法度中の御法度です。
 
また、そのテーブルを参照する選択クエリが存在した場合、
テーブル作成クエリの実行に伴ってそのテーブルが
定義ごと削除されることにより、それらのクエリが
破損してしまうリスクが高まります。
 
引用:
追加クエリの方が良いですか?
でも考えてみれば、テーブル作成クエリを使っているので、
[テーブルB]のレコード削除クエリの必要性が今はあまりないですよね。

引用:
2.[テーブルA]からIDが9から始まるものだけを抜粋する
テーブル作成クエリを実行して[テーブルB](約5000件)を作っています。

上記の操作に関しては、
 
2-1. [テーブルB]の全てのレコードを削除する削除クエリを実行する。
 
2-2. [テーブルA]のうち、[ID]が 9 から始まるレコードを抽出し、
     [テーブルB]に追加する追加クエリを実行する。
 
という流れにした方がよいでしょう。
 
引用:
それぞれのローカルにコピーしてから作業するというのは
確かにリスクを軽減できると思いますが、おそらくみんな面倒だから
やりたくないとか、忘れてそのまま共有フォルダのアクセスを
触ってしまうが必ず出てきてしまうので徹底するのが難しいです。

今まで通りの運用を続けられる限り、事態が好転することはないと思います。
(理由は前述した通り)
 
引用:
VBAの修正がちょいちょい入るため、1つのファイルで管理したいという
私のワガママで管理しているのが現状です。

せめて開発環境と運用環境は分離しましょう。ろくなことになりません。
 
例えば Access のバージョンが異なるクライアント間で
1 つのフロントエンドデータベースを共有することによって、
その中のオブジェクトや VBA プロジェクトが破損する
恐れがあります。
 
Suzu さんが回答されているように、バックエンドデータベースと
フロントエンドデータベースに分割し、ローカルドライブに保存した
フロントエンドデータベースを各ユーザーに操作させるようにした方が安全です。
 
引用:
Windows 8 : Access 2007

引用:
色々考えた結果、なぜ3000件になってしまうのかというところは
よくわかりませんが

類似の現象に関する記事:
http://holmes.hatenablog.com/entry/2013/10/15/180042

投稿日時: 19/05/09 21:33:45
投稿者: uni_corn_623

skさま
 
返信ありがとうございます&返信が遅くなり申し訳ありません。
 
 

引用:
1 から 4 までの操作を 1 日 1 回だけ(毎朝 9 時頃に)
実行しているということでしょうか。

そうです。
 
 
引用:
ならデータベースの最適化も操作 4 を終えた直後に、
1 日 1 回だけ実行されるようにした方がよいと思います。
(と同時に、データベースのバックアップを行なうことをお奨めします)

承知しました。
そうしてみます。
 
 
引用:
また、[閉じるときに最適化する]オプションが有効になっている
データベースに関しては、一部の実行環境において
「最適化の際にエラーが発生する」とか
「データベースファイルが消失する」といった現象が
過去にも報告されています。

それは知りませんでした。
あまり推奨されていないものだったんですね。
今後気をつけます。
 
 
引用:
データベースの最適化に失敗した場合も含まれます。

やはり強制終了時に最適化に失敗していそうですね。
 
 
引用:
もしテーブル作成クエリを実行しようとした際に(他のユーザーが)
その既存のテーブルに開いていた場合、テーブル作成クエリを
実行することは出来ません。

共有フォルダで管理しているので誰かが開いているかはわかります。
そして誰が開いているかもわかるようになっているので誰かが開いていたら開かないようにしています。
必ず使用する人は一人とルールとして決めていますので同時に使うことはありませんが
テーブル作成クエリではなく追加クエリに変更しようと思います。
 
 
引用:
せめて開発環境と運用環境は分離しましょう。ろくなことになりません。

引用:
Suzu さんが回答されているように、バックエンドデータベースと
フロントエンドデータベースに分割し、ローカルドライブに保存した
フロントエンドデータベースを各ユーザーに操作させるようにした方が安全です。

そうですよね、、改修します。
 
 
引用:
類似の現象に関する記事:
http://holmes.hatenablog.com/entry/2013/10/15/180042

リンクありがとうございます。
同じ現象がやはりあったのですね。
まず、閉じる時の最適化をやめて、バックとフロントに分けます。
色々とご教授ありがとうございました!

回答
投稿日時: 19/05/13 11:37:36
投稿者: Suzu

uni_corn_623 さんの引用:

すみません、「サーバーのタスクスケジュラー等で、CompactDatabseメソッドにて、ファイル最適化及びバックアップを行うVBS等を起動させるようにする」の意味があまりよくわかりません。どこかにやり方が記載されているサイトなどありますでしょうか?

 
んーー
Windowsマシンであれば タスクスケジュラーと言う機能があります。
(検索/実行で、「タスク」としてみてください。)
これは、あるタイミングで、プログラム/アプリケーション を実行する機能です。
 
ですで、ファイルに誰もが触っていない時間帯で、
タスクスケージュラーにて、最適化を行ったら良いのでは?と言う事です。
 
 
サンプルです。
 
>---------------------------------------------------------------------------------------------
Option Explicit
 
Call Main()
 
Sub Main()
  Dim DBEng
  Dim FSO
  Dim strPath, strOldFil, strNewFil
 
  strPath = "C:\フォルダパス\"
  strOldFil = "ファイル名.accdb"
  strNewFil = YEAR(NOW()) & RIGHT("0" & MONTH(NOW()),2) & RIGHT("0" & DAY(NOW()),2) & ".accdb"
 
  Set FSO = CreateObject("Scripting.FileSystemObject")
  If FSO.FileExists(strPath & strOldFil) = False Then Exit Sub
  If FSO.FileExists(strPath & strNewFil) = True Then Exit Sub
 
  Set DBEng = CreateObject("DAO.DBEngine.120")
  DBEng.CompactDatabase strPath & strOldFil, strPath & strNewFil, ";LANGID=0x0411;CP=932;COUNTRY=0", 128
   
  FSO.DeleteFile strPath & strOldFil, False
  FSO.CopyFile strPath & strNewFil, strPath & strOldFil, False
End Sub
>---------------------------------------------------------------------------------------------
 
メモ帳に張り付けて、
テスト環境を用意し、フォルダパス、ファイル名を テストの物に修正し、
ファイル名を、〜〜〜.VBS として保存して、ダブルクリックにて、実行してみてください。
 
もしエラーになるのであれば、
 
ファイル名を指定して実行で
C:\Windows\SysWow64\cscript.exe "C:\〜〜.VBS"
として実行してみてください。
 
成功すれば、指定したフォルダに、
・最適化済みのacccdbファイル
・実行した日のファイル名 (今日なら「20190513.accdb」)の バックアップファイル
が作成されるはずです。

投稿日時: 19/05/16 22:04:51
投稿者: uni_corn_623

Suzuさま
 
返信遅くなり申し訳ありません。
ファイルを誰も触っていない時間というのが限られますのでできるときにやってみたいと思います。
 
VBAありがとうございます。
こちらも試してみたいと思います。
お時間を割いていただき本当にありがとうございました。

トピックに返信