Qbasicnews.com
June 20, 2019, 04:27:22 AM *
Welcome, Guest. Please login or register.

Login with username, password and session length
News: Back to Qbasicnews.com | QB Online Help | FAQ | Chat | All Basic Code | QB Knowledge Base
 
   Home   Help Search Login Register  
Pages: 1 [2]
  Print  
Author Topic: "Out of string space" opening a big secuencial fil  (Read 9414 times)
alajandrolieber
New Member

Posts: 7


« Reply #15 on: September 19, 2005, 09:36:59 PM »

Moneo was right.

OPEN will not detect a new record with only 0A as the last character.

So QBasic could not open  the file because it saw it as a one 140Mby long record file.

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.

 Alejandro Lieber
Rosario  Argentina
Logged

he command line is a vestige of an era of macho computing
Moneo
Na_th_an
*****
Posts: 1971


« Reply #16 on: September 19, 2005, 11:20:13 PM »

Alejandro, Please read my comments below.

Quote from: "alajandrolieber"
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.
*****
Logged
alajandrolieber
New Member

Posts: 7


« Reply #17 on: September 19, 2005, 11:47:33 PM »

>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.


All the records are delimited by one LF



>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?


The file was produced by the Argentine goverment.
 


>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?

I have told them the problem in mixing 38 and 39 bytes records.
Nothing happened in the following release.

>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.

I believe you. But the original file is in a CD, so I can try several  ideas.

Alejandro Lieber
Logged

he command line is a vestige of an era of macho computing
Moneo
Na_th_an
*****
Posts: 1971


« Reply #18 on: September 20, 2005, 02:57:05 PM »

Ok, Alejandro, it looks like you are in control of all the information.

So, are you going to run the CSAR program? Later, when you have a new large file with records delimited by CRLF, don't forget to put the following logic that I suggested into your original progam:

..... your original program should include a test of the length of each record. As per your specifications, the records must be 48 or 49 bytes long. If your program finds a record that is not 48 or 49, then there was some file conversion problem.

You should also add a record count to the program, printing it out at the end, to insure that the number of records processed coincides with your original specifications.

Let us know of the results or any new problems. Good luck!
*****
Logged
alajandrolieber
New Member

Posts: 7


« Reply #19 on: September 21, 2005, 07:08:55 PM »

Moneo:

Tu ayuda ha sido imprecindible.


Muchas gracias, espero poder ayudarte algún dia.

Alejandro Lieber
Rosario  Argentina
Logged

he command line is a vestige of an era of macho computing
Moneo
Na_th_an
*****
Posts: 1971


« Reply #20 on: September 21, 2005, 09:54:35 PM »

Quote from: "alajandrolieber"
Moneo:

Tu ayuda ha sido imprecindible.


Muchas gracias, espero poder ayudarte algún dia.

Alejandro Lieber
Rosario  Argentina

Alejandro,
De acuerdo, gracias, estoy a tus ordenes.

Pero cuéntame, ¿como te fue, qué pasó? Si no quieres ventilar esto aquí, escríbeme al:
moneo@prodigy.net.mx

*****
Logged
Pages: 1 [2]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!