過去の桐井戸端BBS (桐ver.8)
10419 「データファイルが壊れています」等のエラーについて Rockey 2001/03/21-13:14
早速、表題の件ですが.....
V8になってからと言うか、Windowsになってからいろいろなパターンがあるような気がします。

1.ファイルを開こうとすると
[データファイルが壊れています]と表示して開けないが、表定義だと再定義できて再定義後、開くと修復できている
2."開く"も"定義"も
[データファイルが壊れています]と表示して桐の"表の修復"でないと修復できない。
3.「ファイル識別コードに異常が...」と言うメッセージ
4.開くことができ、項目集計、追加、修正が可能、しかし、表整理をしたところ[データファイルが壊れています]と表示します。
このときは再定義もできませんでした。

ちなみにシステムはサーバー1、クライアント3でのデータ同時入力で、サーバーのTBLをクライアントが
開きますがスピードの関係で共有更新ではなく専有で開いています。
印刷も行っていますが、基本的には参照モードで開いて必要なデータを作業表に書き出し(読み込み)て印刷しています。
今のところどういう状況でファイルが壊れるかわかっていません。

クライアントで作業TBLに入力後、サーバーの実データに併合させ、誰かが併合中には開けるまで待っています。
1件の併合なのでサーバのデータ量が多くてもスピード的には問題ありません。

一括処理(イベント)で表を開いてみて開けた場合のみバックアップをするように設計していますが、
1.2.3の場合は有効ですが、4.の場合は壊れたTBLをバックアップしてしまいました。
4.の場合はバックアップしてあったTBLの枠組みを書き出してから、その表に壊れたTBLを読み込んだら修復しました。(??)

現システムは、営業所5カ所で稼動していますがシステム稼働後4ヶ月で4.が2件、1.が2件ありました。
一括処理(イベント)の作り方がわるいのかな?

ファイルが壊れるのを最小限に防ぐ工夫や、壊れた時の対処方法など体験談をお聞かせいただければと思い投稿しました。

よろしくお願いします。

10432 Re:データファイルが壊れています ezer 2001/03/22-01:20
記事番号10419へのコメント
Rockeyさん はじめまして超初心者のエゼルと申します。

私なりにコメントを差し上げます。桐の使用環境によっていろいろな現象が出ることもあるかと思われますが、
私がまず疑うのは桐ではなくWINDOWSの方を疑います。
桐自体のデータがそのような不安定なRDBとは考えにくいので!!
まずWINのレジストリーエラーがあるかシステムファイルのエラーかウィルスかいろいろな原因が考えられるような気がします。
尚、バックアップの件ですが、表を開いたら必ずバックアップしてしまうと
必ず壊れたファイルをバックアップしてしまうことになります。
この場合には桐にてバックアップありにして本当のバックアップは別の方法でとるのが良いような気がするのですが
いかがなものでしょうか?

私も桐8と格闘中です。
Rockeyさん はこのシステムを桐8で営業所5カ所で稼働していらっしゃるとのことですから、
一括処理(イベント)の問題というよりもWINDOWSを疑うべきなのではないでしょうか。
但し、私は超初心者であることをお忘れなく、はずしていたらごめんなさい?
10435 Re:データファイルが壊れています Rockey 2001/03/22-10:27
記事番号10432へのコメント
ezerさん、コメントありがとうございます。

>尚、バックアップの件ですが、表を開いたら必ずバックアップしてしまうと必ず壊
>れたファイルをバックアップしてしまうことになります。この場合には桐にてバッ
>クアップありにして本当のバックアップは別の方法でとるのが良いような気がする
>のですがいかがなものでしょうか?

今までは、壊れたファイルは開けないものだと思っていました。
そこで、開けたtblだけファイル複写またはファイル更新でバックアップをするようにしました。
今回は開け留野にも関わらず、表整理をしたら壊れているのがわかったと言う初めての経験でした。
併合の場合はエラーは出ませんが、データは更新されないと言う現象でした。

>一括処理(イベント)の問題というよりも
>WINDOWSを疑うべきなのではないでしょうか。

windowsの問題となると、なかなか難しくなりますね...

説明不足でしたが、OSは WIN98SE、WINMEとも同じように壊れました。

桐でバックアップするとした場合、現システムでは1件入力するたびに実データを開いて、
併合した後閉じるようにしていますので入力速度が遅くなると思い、バックアップはなしにしています。
これは私の先入観でこれまでも全てそうしています。

もう少し、様子を見て調べてみます。

10436 きちんと再定義してなかったのでは 佐田 守弘 2001/03/22-11:49
記事番号10435へのコメント
Rockeyさん
話の筋からの推定になりますが、MS-DOS版の桐のデータから現在のWindows版へは、どの様に移行されましたか?
もし単にWindows版で編集を行っただけであったとしたら、そのあたりに原因があるかも知れません。
そして、もう少し詳しくいうと、例えばMS-DOS版の桐ver.3あたりのデータから、
再定義せずに桐ver.4→桐ver.5と使い続けて来たとしたら、その様な現象は考えられます。

これは、各バージョンで再定義を行わずに。単に編集する事によってデータコンバージョンを行った場合、
旧バージョンの定義情報がきちんと変換されずに、ゴミとして残ってしまう場合があります。

私の経験でいえば、桐ver.3で初めて作ったデータを桐ver.4で使い、その後桐ver.5で使った頃に、
定義内容の異常に基づくエラーが見つかりました。
原因について細かい事をいえば、それぞれのバージョン特有の細かい定義方法の違いがあり、
再定義せずに自動変換だけを行うと、その部分のきちんとした変換がされないためです。
そして、それが世代を経た後に表面化する事があると思います。

その様な訳で、障害を起こす表については、現在のバージョンで再定義を行ったかを確認して下さい。
おそらく再定義をすれば、異常現象はなくなるはずです。
そして、それでもだめな場合、定義内容をK3形式に書き出し、改めてそのK3ファイルから表を作り直して下さい。

付け加えますが、桐の表は正しく使っていれば、そう簡単に壊れるものではありません。
(ただし、壊そうと思えば壊せます。)
私にとって、桐の表は日本銀行の金庫みたいなもので、データの保管場所としては一番安心していられます。

佐田守弘(KS-00119)

10439 Re:きちんと再定義してなかったのでは Rockey 2001/03/22-12:37
記事番号10436へのコメント
佐田 守弘さん、コメントありがとうございます。

表はV5で新規作成しました。
V8にアップするに際しては項目の追加があったので再定義しております。

おっしゃるとおり、表の定義をK3に書き出して再作成してみる方法もあるかなと思います。

また、運用の方法など現地で確認してきたいと思います。

ありがとうございました。

10446 Re:レジストリーは大丈夫? ezer 2001/03/22-16:45
記事番号10439へのコメント
Rockeyさん 超初心者のエゼルです。

レジストリーチェッカーでチェックされましたか?
念のために

98SE ではWINDOUSをMS-DOSで再起動しコマンドプロンプトから
   SCANREG /FIX
Meではファイル名を指定して実行から
   SCANREG /FIX
もう、作業済みでしたら、余計な心配でした。

戻る