Windows native and system copy

[Kenneth Brody]

Quoting GCC Consulting (Mon, 21 Mar 2005 19:41:46 -0500):

> I had created a process that copies a file from one computer to a server
> and renames the file using the system command.
> 	copy upstrack.csv f:\temp\ups032105.txt
[...]
> However, when run from the task manager the first part of the program
> worked, the copy/rename.  However, the import function failed.
>
> After talking with Nancy Palmquist, she confirmed what I had suspected.
> I had placed a sleep 5000 prior to the import.  This let the program
> take a break for 5 seconds before the import ran.  With this in place,
> the program ran perfectly.
>
> Nancy has had some conversation with ken about this problem and he has
> said that sleep isn't necessary.  However, Nancy and I feel that, at
> least in a network/Windows environment, processing returns to the
> processing table before the new file has had a chance to close.  It
> will exist, but won't be closed and available for import or whatever.
>
> By delaying processing those few seconds, it clears the problem.
[...]

While I don't doubt that the sleep fixes the problem on your system, I
can tell you that this means that your system is broken.  Unless you
tell the O/S to run the copy in background, the copy will be complete,
the file will be closed, and it will be available for anyone to access,
prior to it returning.  If control returns to filePro before the file
is actually copied, then either you explicitly told Windows to run the
copy in background (via "start"), or your system is broken.

--
KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
http://www.hvcomputer.com
http://www.fileProPlus.com