Wednesday, April 23, 2014

Moving Files: Two Methods

The Issue

My standard method of performing periodic work is to start with all files needed to create the output in a single folder.  (There are exceptions, but this applies to most of them.)  These are typically put into a folder with the highly imaginative name of "Inputs", or sometimes the name of the system that provides them.

After processing each file needs to be moved elsewhere, for several reasons. 
  • Archiving input files in their original condition provides an audit trail
  • If a process needs to be re-run then the file can be retrieved back to the Inputs folder.  
  • It acts as an indicator the file has been processed subsequent runs can ignore it.  Otherwise a table for what inputs have been processed must be built and updated as each file is worked.
I have found two methods for doing this.  Each has their advantages.

Method 1

This is the first one I discovered.  It uses two steps:
  1. Copy the file to the new directory 
  2. Delete the original
     FileCopy Inputs_Dir & filelongname, Processed_Dir & filelongname
     Kill Inputs_Dir & filelongname

This is comparatively better because it works across drives, very useful when moving files may entail shared (i.e. network)  and local folders.

An advantage of knowing this method is each piece is useful on its own, i.e. there are times when old files need to be deleted and there are times when copies need to be made while keeping the original.

I'm not enthused by the naming, though.  

"Kill" is more akin to what is done to a process, something moving, rather than something stationary.  Maybe "Erase" would have been better, or "Nuke".  Also, it is inconsistent with the name for "FileCopy".

Method 2

    Name Inputs_Dir & filelongname As Processed_Dir & filelongname

I like this because it is only one chance for me to mess up the code.

On the downside, it does not work when moving from one drive to another.  

On a style note, I don't like the syntax.  The "As" off from what I am used to seeing.

Also, "Name" is confusing because it is used elsewhere in VBA, e.g. many objects have a "Name" attribute and there is the Names collection.  Perhaps "ReName" would have been better.  After, that's got a history back to DOS.

No comments:

Post a Comment