input statement, file without vbcr

  • Thread starter Thread starter ykkfc
  • Start date Start date
Y

ykkfc

Each text file has its records separated by a vblf
character. There isn't any vbcr character in it so I
cannot use "line input" in my code. The file size is
unknown. What is the best way to open and read its content?

At present I use these 2 statements to process the data:
Open <my-file-name> for input as #1
Line input #1, tmpStringVariable

So I did not specify the buffer size in the open
statement. It looks to me the whole file is just read in
ok. My codes search for the character vblf to find out
where a record ends (and the next record starts).

I think even if the input file is very large, the system
will be able to handle it without problem. Can someone
confirm me?
 
According to Access VBA help, a string variable can contain up to 2^31
characters. In practice the limit will probably be set by the available
virtual memory on your computer.

One alternative approach would be to change the record separators before
opening the file. There are lots of utility programs that will do this:
search the web for "Unix to Dos converter" or similar and you should
find one to download.
 
I had a little time on my hands, so I decided to have a go at tidying up
that old code. Here's the cleaned-up version.

Public Sub LF2CRLF(ByVal strInput As String, ByVal strOutput As String, _
Optional boolReplace As Boolean)

'strInput - path/name of input file
'strOutput - path/name of output file
'boolReplace - if True, when finished, kill input file and rename output
file same as input file

'Errors are passed back to calling code. Purpose of error-handling code
within procedure is to ensure that file handles are not left open

Dim lngErrNumber As Long
Dim strErrSource As String
Dim strErrDescription As String
Dim strErrHelpFile As String
Dim strErrHelpContext As String

Dim intInput As Integer
Dim boolInput As Boolean
Dim intOutput As Integer
Dim boolOutput As Boolean
Dim strChar As String

On Error GoTo ErrorHandler
intInput = FreeFile
Open strInput For Input As intInput
boolInput = True
intOutput = FreeFile
Open strOutput For Output As intOutput
boolOutput = True
Do Until (EOF(intInput))
strChar = Input(1, #intInput)
If strChar = vbLf Then
strChar = vbCrLf
End If
Print #intOutput, strChar;
Loop
Close intInput
boolInput = False
Close intOutput
boolOutput = False
If boolReplace Then
Kill strInput
Name strOutput As strInput
End If

ExitProcedure:
On Error Resume Next
If boolInput Then
Close intInput
boolInput = False
End If
If boolOutput Then
Close boolOutput
boolOutput = False
End If
On Error GoTo 0
If lngErrNumber <> 0 Then
Err.Raise lngErrNumber, strErrSource, strErrDescription,
strErrHelpFile, _
strErrHelpContext
End If
Exit Sub

ErrorHandler:
With Err
strErrDescription = .Description
strErrHelpContext = .HelpContext
strErrHelpFile = .HelpFile
lngErrNumber = .Number
strErrSource = .Source
.Clear
End With
Resume ExitProcedure

End Sub
 
Brendan,

Much appreciated. But not sure if you mean you suggest to
convert the file by replacing vblf with vbcrlf and then
read the replaced file with line input statement. Do you
mean it is better to do it that way?

Originally I said I had written my codes with the "Line
Input" statement (essentially the program needs to read
the whole file with one statement, because there is no
vbcr character). I run the code for a small file, it looks
it runs perfectly. But when I run it for a large file (1
mb), I did encounter a problem. What makes you think there
is problem in my codes?
 
I don't know for sure that grabbing the whole file is going to cause a
problem. I do know for sure that converting the line endings works well,
because I have an app that's been doing that on a daily basis for several
years.

My instinct would be to avoid making such a heavy demand on memory if I
don't have to. True, memory is not quite the scarce resource today that it
was in the past - but then most of us tend to have more applications and
services loaded then we did in the past, too.

What was the problem you encountered with the large file?
 
Thks Bren. What APPEARs to me (though the box has 512 mb)
is a memory issue.

The program runs slower (compare with breaking up vblf).
Then it appears to stop as soon as I SELECT another
Windows task (say by pressing alt-tab or click on another
Windows. I just "select" and not working on it at all. The
second Windows is in idle state.) Then I have to press
ctrl-break and hit continue to make the original task run
again.

Though I'm aware of the method to change vblf, I am not
exactly sure what causes it stop. So I try to find if
others encounter the same in his/her box.
 
Back
Top