Alejandro, Please read my comments below.
Moneo was right.
OPEN will not detect a new record with only 0A as the last character.
NO. "OPEN" DOES NOT DETECT RECORD DELIMITERS. THE PROBLEM OCCURS ON THE "LINE INPUT".
So QBasic could not open the file because it saw it as a one 140Mby long record file.
AGAIN, NOT A QBASIC "OPEN" PROBLEM. THE FIRST EXECUTION OF "LINE INPUT" SAW THE HUGE RECORD.
I have the program GSAR: General Search and Replace Utility by Tormod Tjaberg.
It seems it can do what I need:
gsar -ud -o file.txt
will rewrite file.txt replacing each 0A with 0D0A (UNIX to DOS)
I will try it next wednesday.
IN A PREVIOUS POST, I MENTIONED AT LEAST 5 OTHER COMBINATIONS OF RECORD DELIMITERS WHICH "COULD" APPEAR ON THE FILE. UNLESS YOU ARE ABSOLUTELY SURE THAT ALL THE RECORDS ARE DELIMITED ONLY BY ONE LINE FEED, THEN THIS GSAR PROGRAM WILL NOT WORK AND ONLY SCREW UP THE RECORD DELIMITERS EVEN MORE.
IF YOU KNOW EXACTLY HOW MANY RECORDS THE FILE HAS, YOU COULD USE XTREE OR OTHER UTILITY TO COUNT THE NUMBER OF LINE FEEDS THAT ARE ON THE FILE. IF THESE COUNTS COINCIDE EXACTLY, THEN YOU CAN USE THE GSAR UTILITY.
Alejandro Lieber
Rosario Argentina
Alejandro,
Where was this file produced? Was it on Unix? Is it a "print file"? Are you familiar wht the program or utility that produced the exact version of this large file?
I've asked you these questions before, but you don't answer. You seem to want to find alternative solutions. I've told you before that I was confronted with this problem before. It is not a simple problem, and the solution is not simple either.
The simplest solution, as I've said before, is to go back to the source of the data file, and request a version with records delimited only by CRLF. Is this option not feasible?
Again, if you run the GSAR program without the assurance that ALL the records are delimited only by one Line Feed, that is, without having counted, then you will be headed for disaster. Believe me.
*****
