With some files, sometimes this syntax fails to read in the textfile a line at a time. In these cases it reads the whole file at once:


Open pathToFile For Input As #1
Do while Not Eof(1)
dim txt as string
Line Input #1, txt
Loop

In this case, the loop only runs once and Len(txt) outputs 133,747 chars (it's a 131KB file).

Why does it work fine with some files and not with others? As far as formatting, the files look identical in style and the content is virtually the same.

Two things

1. Take the Dim statement out of the loop it needs to be outside of the loop as it only needs declaring one.

2. Have you tried opeing the offending file in notepad/wordpad? It could be that when it was created there was no carriage return after each record.
If it still persists have you tried it on a different pc?

David

It is because the file is (probably) generate on a linux/unix system.

There linefeeds are enough to stipulate a next line, in windows you need a cariage return to do the same.

Two things

1. Take the Dim statement out of the loop it needs to be outside of the loop as it only needs declaring one.

2. Have you tried opeing the offending file in notepad/wordpad? It could be that when it was created there was no carriage return after each record.
If it still persists have you tried it on a different pc?

David
Thanks David. What I posted was intended to be more readable. In the actual code the Dim is before the loop. Here's the actual code:

Dim TextLine As String, textFileOrig835 As Long
textFileOrig835 = 1 'read in the file and parse it.
Open pathTo835 For Input As #textFileOrig835 ' Open file.
Do While Not EOF(1) ' Loop until end of file.
Line Input #textFileOrig835, TextLine ' Read line into variable.
'more code here
Loop
The code works fine for hundreds of files. Every once in a while it fails. I changed it to use FileSystemObject (TextStream) and now this file works. But this is scary - what happens if the new method fails on other files? And what about all the other places in my code where I use the old method? Will that fail me too? I want to get to the bottom of this so I can avoid problems in the future.

The data is downloaded from insurance companies. Our IT dept has a program (written in Visual Basic and runs on my Windows XP machine) which parses the data as to make a plain text file. There are hundreds of these files weekly, and most of them work fine with my code. I read in the plain text files, not the downloaded data.

It is because the file is (probably) generate on a linux/unix system.

There linefeeds are enough to stipulate a next line, in windows you need a cariage return to do the same.
See my last post. This is not a linux system.

No, I think what mailman meant was that if the file *originated* in a linux/unix system, then it would have a LF at every line, rather than Windows' CRLF.

If you have a Textpad or Notepad++, they can tell you whether it's a LF-feed or a CRLF-feed. See if this is the cause.

No, I think what mailman meant was that if the file *originated* in a linux/unix system, then it would have a LF at every line, rather than Windows' CRLF.

If you have a Textpad or Notepad++, they can tell you whether it's a LF-feed or a CRLF-feed. See if this is the cause.
I don't have either of these apps. Maybe I'll try parsing the text myself to figure that out.

FWIW, you can download and use Textpad for "free". (It does cost $35, but the evaluation period is unlimited with intermittent reminder)

It's not the cost - it's that I have to avoid installing unecessary software to avoid conflicts with the IT dept.

Aha.

Just thought of one more possible way to figure this out- with your current code opening the textfile, do a InStr() upon the resulting string and see if it contains a CRLF (that'd be Chr(10) & Chr(... something..). If you get zero, then you should know that there wasn't any CRLF to be found in that text file.

Thanks guys - you guys were right. I parsed two files that visually look identical. The one works, the other doesn't. With the one that works, each line ends with

vbCr & vbLf (carriage return plus line feed)

And with the one that doesn't work, it only has the line feed.

Thanks guys. I guess I'll use FileSystemObject (TextStream) from now on, I hope that will work.

Or just spin the file into a new file, adding in the CR where only the LF excists.

Or (what I usually do) go back to the source and tell them to deliver consequent source files... give the files in one way only.