I am doing a simple Read Parse and output of a large ASCII file (~350MB).
The problem is that the Readln seems to be eating up all my memory. After I
read in about 50MB my physical memory is exhausted and the HD thrashes like
crazy. I commented out the writeln just to make sure that those were not
the problem and my assumptions were correct. I tried updating the
System.dsu(or dcu) from the Borland website, but that didn't help. Has
anyone encountered any problems like this ???

Joe,

Hi

Does the file you are reading only have linefeeds (ex UNIX) or carriage
return/linefeed (ex MS-DOS) at the end of each record. Delphi Readln
requires the later. I have had to write my own input routine to handle
the former.

Hope this sheds some light on your problem.

Phil E  

unit CharFile;

{ The TCharFile is used to read lines from a text file.
  Ordinarily, a file variable of type TextFile would be used,
  but TextFile assumes that lines are separated by #13#10.
  This is true for Windows and DOS text files, but
  not for e.g. UNIX text files, which are normally
  separated only by #10.

  Using ReadLine with a TCharFile is like
  using ReadLn with a TextFile,
  but ReadLine accepts any combination of #13 and/or #10
  characters as line separators. (This also means that "empty lines"
  cannot be read, because there is no way to define what is
  meant by an empty line - lines "intented to be empty" will be "skipped",
  they are "not seen" by ReadLine.)

  Original author: Matthias Bolliger

type
  TCharFile = file of Char;

{ Read a line from a file. Lines are separated by any number
  of #13 and/or #10 characters. }
procedure ReadLine(var filein: TCharFile; var strin: string);

implementation

procedure ReadLine(var filein: TCharFile; var strin: string);
var
  ch: Char;
begin
  strin := '';
  while not (eof(filein) or (ch in [#10, #13])) do begin
    Read(filein, ch);
    if not (ch in [#10, #13]) then strin := strin + ch;
  end;
  while (not eof(filein)) and (ch in [#10, #13]) do Read(filein, ch);
  if not eof(filein) then Seek(filein, FilePos(filein) - 1);  { Back one
character }
end;

end.

Phil,

I guess I could check this to make sure, but I just don't see where that
should cause a problem. I am writing over the same string variable with
each successive line so it should be eating up any more memory. I will
definitely try this to see if that is the problem. I can tell you that I
ported the same App to VB and am using the "Line Input" command which is
the equivalent Delphi command. With the exception that VB runs slow as
hell, it runs just fine. Very confused????????????? I really hate to have
to use VB to process this stuff but have no Delphi alternative.

Joe,

Phil Eldridge <peldr...@voyager.co.nz> wrote in article
<5b2cb9$...@reader1.reader.news.ozemail.net>...

Had the same problem, check the following:

Check if you use string-type variables in the readln statement. If you do,
make sure you use the shortstring or string[255] type declaration for this
variable if the maximum length of your data don't exceed the limit of
255 characters. You can also use the compiler directive $H.

Norman Sigarlakie

Norman,

Unfortunately I can't do this. My file has a record length of 3500
characters.

Joe,

Norman Sigarlakie <g...@worldaccess.nl> wrote in article
<01bc02d4$db791880$LocalHost@gino>...

Is it possible to cut your data into smaller parts ?
If so, you still can use the short strings in the
read statement.
For example, I have client-records and each record
is presented as an flat ASCII string exceeding 255
characters in total. Because I know the exact length
of each 'field', I can define the variables for each
of them as a string of fixed length and use it in
the read statement:

...
var
  { these variables are for local use and
    to store values temporarily }
  Name, Department, Contact,
  Address, City: String[35];
  PostalCode: String[10];
  Phone, Fax: String[20];
  SourceFile: Text;
...
begin
  { prepare for read from file }
  ...
  { read all records from the file }
  ...
  ReadLn(SourceFile, Name, Department,
                     Contact, Address,
                     PostalCode, City,
                     Phone, Fax);
  ...
  { convert the values to your needs }
  ...
end;
...

HTH,
Norman

Joseph M. Day schreef in artikel <01bc082e$90ccf400$6020fdcd@gangster2>...