Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Programatically reading/writing LARGE text files
Message
De
22/08/1999 13:11:27
 
 
À
22/08/1999 05:29:47
Dragan Nedeljkovich
Now officially retired
Zrenjanin, Serbia
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Divers
Thread ID:
00256287
Message ID:
00256407
Vues:
24
>>>>I want to build a VFP program that will determine, and allow setting about 30 variables that will be used to add, delete, or modify lines in what is effectively an INI file. The problem is that this file can range up to about 50 or 60 MegaBytes in size. I read in the VFP help file on System Capacities that the Maximum # of characters per character string or memory variable is 16,777,184 … about 1/3 the size of my file.
>>>>
>>>>I plan to read the file size, and use a straight forward approach (reading it into memory and manipulating it there) if it's small enough, but now I need an approach that will work with files I find that are larger than about 16 MB.
>
>Pardon me if I'll sound stupid, but why don't we determine the length of the longest line (say, 240), create a cursor with a single field like this:
>
>create cursor temp (row c(240))
>append from the_long_file.txt sdf
>

As long as the file is in fact broken down line by line, this would probably work. If you need to work with things that can cross a line this would be a PITA, but it sounds like his file is processed line by line IAC.

If it is a text file, he could also access it via ODBC.

In my case, I'd probably pull it into cursor in a memo field and work on it there if I needed to work on it more than a line at a time, or as mentioned, pull it into a table, and then create some filtered indexes to make finding sections easier.


>then manipulate the rows in the cursor in whatever fashion you like, and dump them back, trimmed? We won't run into large memvar issues, and would have all the ease of record manipulation.
>
>Another approach would be to keep a side table with offsets of important lines (did anyone say sections?) in this file, or possibly the lengths of the chunks, and use these as indexes into the file. Using these offsets, the file may be manipulated using LLFF - provided the lengths of the lines don't change. If they change, this won't work, of course. I've used this "byte offset into a text file" approach once on a Vax, but the file was read-only, so I needed to calculate the offsets only once, and actually indexed only the first records in a group (it was a warehouse history, sorted by item code, cobol sequential).
>
>Anyway, I think that manipulating that big a text file will need a lot of (re)thinking. I'm actually interested to hear the details - this sounds like a strange problem.
EMail: EdR@edrauh.com
"See, the sun is going down..."
"No, the horizon is moving up!"
- Firesign Theater


NT and Win2K FAQ .. cWashington WSH/ADSI/WMI site
MS WSH site ........... WSH FAQ Site
Wrox Press .............. Win32 Scripting Journal
eSolutions Services, LLC

The Surgeon General has determined that prolonged exposure to the Windows Script Host may be addictive to laboratory mice and codemonkeys
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform