プロが教える店舗&オフィスのセキュリティ対策術

客先に納入したVBのプログラムなのですが、先日「75:パス名が無効です」のエラーが発生しました。

エラーが発生した部分はファイルをオープンし、読み込む処理を行っているところです。
このファイルは他のプログラムからもアクセスすることがあるためオープン時にロックして処理を行っています。

「55:ファイルは既に開かれています」や「70:書き込み出来ません」のエラーが発生することは分かっていたのでエラートラップを仕込んであります。

以下にその処理を抜粋しました。
intFileNo = FreeFile()
Open strFileName For Random Lock Read Write As #intFileNo Len = Len(udtHeader)
…(ここにエラートラップ処理が記述してあります)
Get #intFileNo, 1, udtHeader
close
※strFileNameには読込対象となるファイル名が格納されます。iniファイルから読み込んだ値と固定文字列から生成しているので空白になっていたりすることは考えられません。
※udtHeaderはレコードで読み書きするためのユーザ定義型変数です。

上に記述した他のプログラムも同様の処理でファイルアクセスを行っています。
ファイルオープン前にファイルの有無チェックは行っています。

この中の処理で「パス名が無効です」が発生する要因が分からず困っています。
自分だけではなく他のプログラムもアクセスすることが要因としてあるだろうとは思うのですが、どのような状況になれば発生するかが分かりません。

もし、なにか分かる方がいらっしゃいましたらご教授お願いします。

A 回答 (4件)

「パス名が無効」というキーワードにて


私の記憶が反応し、その材料をもとに考えられるものとして…

・現場では、アクセスするファイルを格納しているディレクトリの
 パス中にスペースが入っている。

この場合、推測される動きは
スペースの部分でパス名が区切られてしまうため
Open処理は成功したっぽい動きをしてしまう。
しかしGet処理では目的のファイルは存在していないうえ
アクセスしようとしているパス自体が存在していないために
「パス名が無効です」というエラーになると考えられます。
これ「C:\Documents and Settings\~~」とかに格納していると発生してしまうという
とある分野では盲点をつかれた微妙に有名な現象。
対策はダブルクォーテーションでくくった格好で指定するらしいです。
似たようなものに、単純にパス名が長過ぎというのがあります。


・連続稼動しているため、別の部分の影響が溜まりに溜まって
 結果、その部分が被害を受けた。

この場合、乱暴な言い方をするなら
「そのソースが関わっている全てのリストが調査対象」
となってしまいます。
どこかの変数の領域確保の大きさが間違っていたり、
想定以上のデータを処理が発生した影響により
結果、パス名を格納している部分のメモリが破壊された。
VBで発生しうるものかどうか判りませんが
しうるかどうか判らないからこそ
稼働環境を考えると可能性が高いともいえます。
客先で確認可能でしたら、Open 前後、Get 前後に MsgBox でもで
パス名を表示させてみてもよいでしょう。
件数や時間など、なんらかの特定のタイミングで発生しているなら
どこかでファイルを開きっ放され過ぎ~~の結果、オープンできなかった。
(つまり #inrFileNo が不定となった。)
けれどエラートラップに捕まってオープンできたフリになった。
なのに Get しようとしたので悲鳴をあげた。

どちらにしても、質問文にある数行のステップでも
稼働時間、データ件数、空き容量などの複数の要素が想定されます。
さて、エラーを引き起こしている正体は
どのような証拠隠滅をしているのでしょう。

あっ、「一つのディレクトリに作成可能なファイル数の上限を超えた」
というのを忘れていました。

以上、ソフト障害プロファイリング遅報でした。

この回答への補足

回答ありがとうございます。

Openするファイルのパスにスペースは入っていませんし、文字数も30字程度なので問題ありません。

既に存在しているファイルに対して処理を行っているので、作成可能ファイル数の上限は大丈夫です。

連続稼働していて、他のプログラムからも同じファイルをアクセスしているためにメモリを破壊してしまうような可能性があるのでしょうか?
何日かはメンテナンスで停止することもありますが、3年間ほど稼働し続けている状態で今までに一回も発生しておらず、発生直前の1秒前にも同じ処理を行っていますが、まったく問題ありませんでした。

メモリが破壊されてしまう可能性を検証することを考えてみます。

補足日時:2009/02/09 19:35
    • good
    • 0

エラーが発生したときにstrFileNameの値は意図したファイルが入っているんですよね?



1つ1つ間違いないのか潰していくしかないですね。
間違いないと思ってたらウッカリってよくあるし。

>「55:ファイルは既に開かれています」や「70:書き込み出来ません」のエラーが発生することは分かっていたのでエラートラップを仕込んであります。

最悪↑の処理にエラー発生時の処理も入れるしかないのかな。

この回答への補足

Open処理の前にファイルの存在チェックを行っていますし、もしファイルが存在しなくても新規に作成するのでstrFileNameに意図したファイル名が入っていなくてもエラーは発生しません。

今回の質問は上記のソースコードで「パス名が無効です」のエラーが発生する要因を教えて頂きたいのです。
エラートラップで回避するようには既になっているので、なぜこのエラーが発生してしまったかを突き止めたいのです。

補足日時:2009/02/09 16:07
    • good
    • 1

他のプログラムってのの挙動を調べる必要はないでしょうか?



たとえば他のプログラムで該当ファイルを削除したりとか移動しているとか。

あとはstrFileNameってのがグローバル宣言されていてどっかのプログラムから値を書き換えられているとか・・・

この回答への補足

回答ありがとうございます。

他のプログラムの動作はこのプログラムと同じ記述でファイル内容を読み込むだけです。ファイルを削除したり、移動したりはしていません。

strFileNameはプロシージャ内で宣言されており、プログラム内の他の部分で書き換えられることはありません。

補足日時:2009/02/09 11:59
    • good
    • 0

こんにちは


素直に考えるとiniファイルの定義が間違っている可能性が一番高い(誤字のたぐい、存在しないディレクトリなど)と思われますが当然確認済みですよね(^^;

この回答への補足

回答ありがとうございます。

説明が不足していましたが、このプログラムは連続稼働(24H)していて、「パス名が無効です」が発生するまでは問題なく動作していました。

iniファイルは起動時に読み込み、その値をずっと保持し続けるのでiniファイルの定義は問題ありません。

補足日時:2009/02/09 11:11
    • good
    • 0

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

このQ&Aを見た人はこんなQ&Aも見ています


このQ&Aを見た人がよく見るQ&A