C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[4]: アクセスデータベースfファイルが壊れる理由

(過去ログ 148 を表示中)

[トピック内 6 記事 (1 - 6 表示)]　 << 0 >>

■86561 / inTopicNo.1)

　アクセスデータベースfファイルが壊れる理由

▼■

□投稿者/ M.S (1回)-(2018/02/14(Wed) 22:39:14)

分類:[.NET 全般]　

Visual Basic 2010 Proffesional
AccessDatabaseEngine.exe(Microsoft Accesss Database Engine 2010)
を使用しています。

ある装置の測定結果ををファイル名.accdbへＳＱＬ文で書き込んでいます。

その際、まれに
「データベースの形式C:\MeasData\Test001.accdbを認識できません。」
でファイルが壊れたようになってしまいます。
ファイルを削除する以外は、読み込みができません。

原因として何が考えられるでしょうか？
対処法は、何か考えられるでしょうか？

引用返信 編集キー/

■86562 / inTopicNo.2)

　Re[1]: アクセスデータベースfファイルが壊れる理由

▲▼■

□投稿者/ ぶなっぷ (167回)-(2018/02/15(Thu) 10:25:33)

接続用のエンジンの指定が誤っていませんか？
データベースの形式に対して、古いエンジンを使っているとか。

以下のような話です。
http://chiroinu.freehostia.com/wordpress/?p=447

引用返信 編集キー/

■86563 / inTopicNo.3)

　Re[1]: アクセスデータベースfファイルが壊れる理由

▲▼■

□投稿者/ WebSurfer (1422回)-(2018/02/15(Thu) 11:20:15)

■No86561 (M.S さん) に返信

> その際、まれに

その「まれ」というのがどういう状況・条件なのかもっと詳しく書けませんか？

完全に同じ環境 / 同じ PC / 同じ .accdb ファイルで、何か月かに 1 回ぐらい問題が出て、
再現性がないということですか？

それとも、ある特定の条件で問題が出て再現性もあるということですか？

前者だと、自分は皆目見当がつきませんけど、後者だとすると、詳しく状況・条件を書いて
もらえると何か思いつくことがあるかもしれません（32 / 64-bit の問題とか・・・2010 用
の ACE には 32 / 64-bit 版の両方があるが共存不可）。

引用返信 編集キー/

■86597 / inTopicNo.4)

　Re[2]: アクセスデータベースfファイルが壊れる理由

▲▼■

□投稿者/ M.S (2回)-(2018/02/19(Mon) 23:24:20)

Windows IOT Enterprise 2016
のＯＳでＵＷＦ機能を使用しています。

電源のぶち切りとかを頻繁に使用します。

プログラムを起動したりした場合や設定ファイルを書き込んだ場合に起こります。
どのくらいの頻度化は、正直よくわかりません。

どういう条件だと必ず壊れるのか再現性が今のところないのです。

引用返信 編集キー/

■86598 / inTopicNo.5)

　Re[3]: アクセスデータベースfファイルが壊れる理由

▲▼■

□投稿者/ 魔界の仮面弁士 (1571回)-(2018/02/20(Tue) 10:09:18)

2018/02/20(Tue) 13:11:21 編集(投稿者)

■No86597 (M.S さん) に返信
> Windows IOT Enterprise 2016
> のＯＳでＵＷＦ機能を使用しています。

ネットワーク共有での利用ではなく、スタンドアロンでの利用でしょうか。
ファイル共有型データベースゆえ、ネットワーク共有での利用は破損率が跳ね上がるのでご注意ください。

以下、mdb 時代の古い記事ですが、基本的には accdb にも当てはまります。
http://www.naboki.net/access/achell/achell_02.html

また、accdb は、スタンドアロン向けのデータベースですので、
可能な限り、単一のコネクションで利用するようにします。
複数のコネクションからの利用が出来ないわけではありませんが、
今回のような利用形態であれば尚の事、コネクションの数を抑える必要があります。

> 電源のぶち切りとかを頻繁に使用します。
そのような利用形態が避けられない場合、未使用時にバックアップをとるなどして
自前でロールフォワードできるように運用でカバーします。

それとデータベースへの読み書きについては、パフォーマンスの向上を目的として、
ACEDAO のキャッシュ機構と OS のキャッシュ機構の両方が利用される仕組みに
なっています。特にライトキャッシュ側につきましては、キャッシュ内容が
ファイルに反映される前（あるいは反映している最中）にプロセスがシャットダウンされると
ファイルの内容は当然不完全な状態に陥りますので、そこは覚悟しておいてください。

軽度な破損であれば修復プロセスで対処できる場合もありますが、酷くなれば
ファイルを開くことさえできなくなることがあります。

これを軽減するには、ライトキャッシュ機能を抑制することです。
そのためには、必ず明示的にトランザクションを張るようにしてください。
要するに、Workspace に対して BeinTrans / CommitTrans を呼び出すということです。

トランザクションを指定しない場合は、即時反映になるように思われるかも知れませんが、
トランザクション無しの書き込みは非同期的、トランザクションありの書き込みは同期的に
行われる設計であるため、トランザクションありの方が破損率は抑えられます。

また、OS のライトキャッシュをフラッシュさせるために、ACEDAO による CommitTrans 時に
dbForceOSFlush オプションを利用するようにします。
　objWorkspace.CommitTrans(CommitTransOptionsEnum.dbForceOSFlush)
ちなみに ADODB 接続時は、
　Const JET_TCM_ASYNCFLUSH As Int32 = 0
　Const JET_TCM_SYNCFLUSH As Int32 = 1
　objConnection.Properties("Jet OLEDB:Transaction Commit Mode").Value = JET_TCM_SYNCFLUSH
です。（ADO.NET や ODBC 接続の場合は、これらに対応するインターフェイスが用意されていません）

> プログラムを起動したりした場合や設定ファイルを書き込んだ場合に起こります。
既に破損した状態で運用していたものの、その領域にアクセスすることが
無かったために問題が出ておらず、その後、たまたま破損している領域に
アクセスした時に顕在化した、というパターンもありえます。

一度、全てのデータを新規ファイルにエクスポートしなおすことも
検討してみてください。

引用返信 編集キー/

■86631 / inTopicNo.6)

　Re[4]: アクセスデータベースfファイルが壊れる理由

▲▼■

□投稿者/ M.S (3回)-(2018/02/22(Thu) 21:31:41)

■No86598 (魔界の仮面弁士さん) に返信
> 2018/02/20(Tue) 13:11:21 編集(投稿者)
>
> ■No86597 (M.S さん) に返信
>>Windows IOT Enterprise 2016
>>のＯＳでＵＷＦ機能を使用しています。
>
> ネットワーク共有での利用ではなく、スタンドアロンでの利用でしょうか。
> ファイル共有型データベースゆえ、ネットワーク共有での利用は破損率が跳ね上がるのでご注意ください。
>
> 以下、mdb 時代の古い記事ですが、基本的には accdb にも当てはまります。
> http://www.naboki.net/access/achell/achell_02.html
>
>
> また、accdb は、スタンドアロン向けのデータベースですので、
> 可能な限り、単一のコネクションで利用するようにします。
> 複数のコネクションからの利用が出来ないわけではありませんが、
> 今回のような利用形態であれば尚の事、コネクションの数を抑える必要があります。
>
>
>>電源のぶち切りとかを頻繁に使用します。
> そのような利用形態が避けられない場合、未使用時にバックアップをとるなどして
> 自前でロールフォワードできるように運用でカバーします。
>
> それとデータベースへの読み書きについては、パフォーマンスの向上を目的として、
> ACEDAO のキャッシュ機構と OS のキャッシュ機構の両方が利用される仕組みに
> なっています。特にライトキャッシュ側につきましては、キャッシュ内容が
> ファイルに反映される前（あるいは反映している最中）にプロセスがシャットダウンされると
> ファイルの内容は当然不完全な状態に陥りますので、そこは覚悟しておいてください。
>
> 軽度な破損であれば修復プロセスで対処できる場合もありますが、酷くなれば
> ファイルを開くことさえできなくなることがあります。
>
> これを軽減するには、ライトキャッシュ機能を抑制することです。
> そのためには、必ず明示的にトランザクションを張るようにしてください。
> 要するに、Workspace に対して BeinTrans / CommitTrans を呼び出すということです。
>
>
> トランザクションを指定しない場合は、即時反映になるように思われるかも知れませんが、
> トランザクション無しの書き込みは非同期的、トランザクションありの書き込みは同期的に
> 行われる設計であるため、トランザクションありの方が破損率は抑えられます。
>
> また、OS のライトキャッシュをフラッシュさせるために、ACEDAO による CommitTrans 時に
> dbForceOSFlush オプションを利用するようにします。
> 　objWorkspace.CommitTrans(CommitTransOptionsEnum.dbForceOSFlush)
> ちなみに ADODB 接続時は、
> 　Const JET_TCM_ASYNCFLUSH As Int32 = 0
> 　Const JET_TCM_SYNCFLUSH As Int32 = 1
> 　objConnection.Properties("Jet OLEDB:Transaction Commit Mode").Value = JET_TCM_SYNCFLUSH
> です。（ADO.NET や ODBC 接続の場合は、これらに対応するインターフェイスが用意されていません）
>
>
>>プログラムを起動したりした場合や設定ファイルを書き込んだ場合に起こります。
> 既に破損した状態で運用していたものの、その領域にアクセスすることが
> 無かったために問題が出ておらず、その後、たまたま破損している領域に
> アクセスした時に顕在化した、というパターンもありえます。
>
> 一度、全てのデータを新規ファイルにエクスポートしなおすことも
> 検討してみてください。

解決済み

引用返信 編集キー/

トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可

- Child Tree -