タイトル : Re: FileCopy でエラー70 書き込みできません 投稿日 : 2010/10/25(Mon) 21:23 投稿者 : 魔界の仮面弁士
> 開いていない場合でも掲題のエラーが発生することはあるのでしょうか? ネットワーク上の問題やライトキャッシュ遅延など、いくつかの要因により アクセスに失敗する可能性はありえるかと思います。 http://support.microsoft.com/kb/321733/ja > 以下のサイトでfilecopyは「推奨しない」と書かれていたので、関係あるのかな? 私は別の問題だと思います。 > 何故「推奨しない」のかも、ご存知であれば、ご教授頂ければ幸いです。 > http://jeanne.wankuma.com/tips/vb6/file/copy.html 個人的には、どちらを使っても良いと思います。たとえば Win9x 系 OS の場合は、 FileCopy の方が優れている面もあります。それは、 ・実行環境に SCRRUN.DLL が無くても動作する(VBの基本ランタイムだけでOK)。 ・95/98/98SE/ME においては、FileCopy の方が FileSystemObject よりも高速。 ・FileSystemObject オブジェクトの作成と破棄にかかるコストが不要。 といった点です。 しかし、NT4/2000/XP/Vista/7 および、サーバー系の Windows で使う場合には、 FileSystemObject 側に大きく有利に働く点があります。Unicode への対応です。 たとえば、ディレクトリ名やファイル名などに、Shift_JIS では扱えない ChrW(&H33A5) …立方メートル "m3" ChrW(&H4F60) …ニイハオの "イ尓" などといったファイル名が使われていた場合、FileCopy では処理できないことになります。 一方、FileSystemObject であれば、Unicode のファイル名でも扱えますし、 さらに、NTFS 代替データストリームさえも扱えるといったメリットがあります。 しかし FileSystemObject は、ディレクトリの走査/コピー/ディレクトリ削除といった 点では有利ですが、ファイルの中身(データの読み書き)は苦手としています。 Shift_JIS や Unicode のテキストファイルに限定すれば、むしろ FileSystemObject の TextStream の方がやや有利ではあるのですが、反面、バイナリデータは一切扱えません。 TextStream の代わりに ADODB.Stream を使えば、バイナリデータも扱えますが、 ユーザー定義型を使った読み書きでは、やはり従来のステートメントが必要です。 なので結局のところ、それぞれを用途に応じて使い分けることになると思います。 どちらでも実装できる部分は、利用者の判断といったところでしょうか。 # たとえば FileSystemObject の方は、構文的には“オブジェクト指向”であり、 # 一方の FileCopy の方は“手続き型”です。そのため、Java などといった # オブジェクト指向プログラミングに慣れた開発者にとっては、FileSystemObject の方が # 分かりやすいと感じるかもしれません。一方で、過去の BASIC に慣れている人などは、 # FileSystemObject の表記に冗長さを感じるかも知れません。 VB6 ヘルプの下記の項も参照してみてください。 [Visual Basic ドキュメント] └[Visual Basic の使用方法] └[プログラミング ガイド] └[Visual Basic を使ってできること] └[ドライブ、フォルダ、ファイルの処理] ├[FSO オブジェクト モデルにおけるプログラミング] └[従来のファイル入出力ステートメントおよび関数によるファイルの処理] |