Last night I was thinking about my old Basic programming, and I believe maybe I was wrong. It's coming back to me, vaguely, that on output statements (repeat "output"), a comma between arguments causes the data to be separated by a tab—either a literal <Tab> character or maybe just a specified number of spaces, I'm not sure—but that a semicolon writes out the data all jammed up against each other, leaving it up to the programmer to decide where to write spaces and so forth.

That's for output. For input, I've an even vaguer notion that commas are more of a problem, maybe an insoluble one, though I'm reluctant to believe it.

Unless someone comes along and straightens us out, I'm about to suggest that you drop the Open, Input and Close statements and use the FileSystemObject. For one thing, it gives you more options when checking drives, paths, dates and other such properties of files. For another—and this is probably the biggest reason—I know how it works .

If you decide you're willing to go that route, or at least to think about it, check out again the code I wrote below and look at Microsoft's on-line documentation here. The point is that the ReadLine method reads an entire line of data at once, leaving it to you to break it up into pieces, which in this case is just what you want.