From: dpb on
Steve wrote:
> On Jul 14, 1:19 pm, "Jim Mack" <no-uce-...(a)mdxi.com> wrote:
>> Steve wrote:
>>> I am using the End Of File (EOF) function within a simple function
>>> to count records in a text file. I have never had problems with
>>> this function
>>> until I began using it to count records in text files which include
>>> lower
>>> value ascii characters in the source text files.
>> When reading 'As Input', the ASCII value (26) is reserved as an "end
>> of file" marker. If you encounter it in text, EOF() is True right
>> there. That is almost surely your issue.
....

> I never know that little nugget about the Open for Input mode!
> I always 'assumed' the file was terminated with a NULL ascii(0)
> value.

^Z was EOF in CP/M which was fairly near dominant so MSDOS picked it up
and while no longer needed specifically for much it's still honored by
much code. (Remember the "/b" switch on COPY, for example?)

--

From: Thorsten Albers on
Steve <stevegdula(a)yahoo.com> schrieb im Beitrag
<23c7fd52-926b-48e3-9039-bf5f07a3c696(a)y4g2000yqy.googlegroups.com>...
> YEP! 23 characters into the first record and more sporadic beyond
> that.
> I never know that little nugget about the Open for Input mode!
> I always 'assumed' the file was terminated with a NULL ascii(0)
> value.

A file isn't terminated by any special byte. The length specification in
the file system's file record (cmp. VB LOF()) only specifies which one is
the last byte.
EOF, as has been said already, is just a statement advising VB to
interprete a certain control code (byte value dec. 26) in a certain way.

--
Thorsten Albers

albers (a) uni-freiburg.de

From: Dave O. on

"Steve" <stevegdula(a)yahoo.com> wrote in message
news:5b3711a5-f0c9-4cdf-b971-9b022cae3b61(a)i31g2000yqm.googlegroups.com...
>I am using the End Of File (EOF) function within a simple function to
> count records in a text file. I have never had problems with this
> function
> until I began using it to count records in text files which include
> lower
> value ascii characters in the source text files.
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Public Function Count_Records(strFilePath As String) As Long
> 'Receive a path to a text file, and count the number of lines
> (records)
> 'If file doesn't exist, then function returns a value of ZERO
>
> Dim intFileNum As Integer
> Dim strCurLine As String
> Dim lngFileLen As Long
> Dim lngRecCtr As Long
> Dim blnPathIsInvalid as boolean
>
> On Error GoTo errHandler
>
> lngFileLen = FileLen(strFilePath)
>
> if blnPathIsInvalid then
> intFileNum = FreeFile()
> Open strFilePath For Input As intFileNum
>
> Do Until EOF(intFileNum)
> Line Input #intFileNum, strCurLine
> lngRecCtr = lngRecCtr + 1
> Loop
> Close intFileNum
> end if
>
> Count_Records = lngRecCtr
>
> Exit Function 'Bypass Error Handling
> errHandler:
> blnPathIsInvalid=True
> resume next
>
> End Function
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> What happens is after the first line of the text file is read via the
> Line Input# function, the EOF function suddenly returns a TRUE value
> and terminates the loop. Of course, there are many more lines of
> text in the source text file which need to be counted.
>
> The structure of the text lines contains regulated data such as ...
> Ascii Data (32 ~126) + chr(14) + Ascii Data(32~126) + chr(14) +
> chr(15) +
> Ascii Data (16 ~ 255) + vbcrlf
>
> There are no vbCRLFchars until the legit end of the line which
> prevents the
> Line Input# statement from prematurely ending the data line read. I
> can't
> seem to explain how the EOF falsely triggers after the first record is
> read.
>
> I have subsequently found a work-around but I would like to understand
> why
> this is failing.
>
> Thanks,
>
> ~Steve

As I see it you are just counting the number of lines in the file - There
are easier methods:

Read the whole file into a variable
Split on vbcrlf
Get the UBound of the resultant array - you may need to add 1 depending on
how the file is terminated.
As an added bonus, you have an array filled with each record.

Regards
Dave O.


From: Steve on
Thanks Dave,

>I have subsequently found a work-around but I would like to understand
>why this is failing.

That is basically what I ended up doing via Binary read into a string
variable, but I wanted to understand why the EOF had failed. Although
I did use this method I am wary because my text files have no
limitations on size and contain data. If they approach the multi
gigabyte size the method approaches its limits.

~Steve

> As I see it you are just counting the number of lines in the file - There
> are easier methods:
>
> Read the whole file into a variable
> Split on vbcrlf
> Get the UBound of the resultant array - you may need to add 1 depending on
> how the file is terminated.
> As an added bonus, you have an array filled with each record.
>
> Regards
> Dave O>




From: Jim Mack on
Steve wrote:
> Thanks Dave,
>
>> I have subsequently found a work-around but I would like to
>> understand why this is failing.
>
> That is basically what I ended up doing via Binary read into a
> string variable, but I wanted to understand why the EOF had failed.
> Although I did use this method I am wary because my text files have
> no limitations on size and contain data. If they approach the multi
> gigabyte size the method approaches its limits.

Here's a trick that will probably allow you to continue what you were
doing. In general, I discourage using strings to handle binary data,
but if you're prepared to deal with the issues, try this:

Instead of using Open xxfile For Input As N, use Open xxfile For
Binary As N -- just substitute Binary for Input.

Then use Line Input # as usual to read lines. Notice that VB no longer
treats Chr$(26) as an EOF marker.

The downside is that VB doesn't know _anything_ about EOF now, so you
have to use an error trap to detect the end of input data. Remember:
errors represent information, not failures.

--
Jim Mack
Twisted tees at http://www.cafepress.com/2050inc
"We sew confusion"

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Run Time Error 1004
Next: Logic behing this Data structure