1. Suggestions for FIlEMAN.E
- Posted by lgregg at BIG12.METROBBS.COM
Feb 18, 1999
-
Last edited Feb 19, 1999
Suggestions for Fileman.e
Like Dbase, how about a status byte as the first character in a record?
To represent a deleted record, place an ASCII 0 there, and an ASCII 1 or
larger code to represent a valid, active record. Thus, when you
delete a record, all you need to do is set the status byte to zero. You
can leave the actual record data alone, which will permit an undelete
later, if you desire.
One record format I read about placed an ASCII 26 after the header
identification. ASCII 26 is the old end of file marker for DOS.
Thus, if you placed such a character at byte position
3, then if the file is read in line mode, by Euphoria or another program,
all they will see is Eu.
I think Ralf mentioned that you should open these files in binary mode.
That way any character from 0 to 255 is permissable and will not affect
the read or write routines.
You will need to have a way to sort the file records. I would think
sorting by some combination of fields would be a nice touch. If you
include the status byte, then you could sort all deleted records to
the end of the file, or simply drop them.
If an area in the header were to be reserved as a pointer to the
first deleted record, you would be able to add a record by reusing
the space occupied by a deleted record. And if that record were big
enough, it could in turn point to the next deleted record.
It might be fun to code a routine to compact the file in place.
That is, you could rearrange the file such that all deleted records
are placed after all the data records, without coping to a second file.
Indexing comes to mind, also.
Larry Gregg
2. Re: Suggestions for FIlEMAN.E
>Like Dbase, how about a status byte as the first character in a record?
>To represent a deleted record, place an ASCII 0 there, and an ASCII 1 or
>larger code to represent a valid, active record. Thus, when you
>delete a record, all you need to do is set the status byte to zero. You
>can leave the actual record data alone, which will permit an undelete
>later, if you desire.
So long as the data hasn't been overwritten by another record, at least..
>One record format I read about placed an ASCII 26 after the header
>identification. ASCII 26 is the old end of file marker for DOS.
>Thus, if you placed such a character at byte position
>3, then if the file is read in line mode, by Euphoria or another program,
>all they will see is Eu.
I've seen this done. For example, in the game, Command & Conquer, you saved
the games by typing in a description, ie, "GDI defending base - About to
win!". The file would be saved like SAVEGAME.004. The first few characters
of the file is the entire description, with a EOF (ASCII 26) marker at like
the 50th position. So, in DOS, "TYPE SAVEGAME.010" would give you the
description of that saved game, and nothing else. I thought this was cool...
>I think Ralf mentioned that you should open these files in binary mode.
>That way any character from 0 to 255 is permissable and will not affect
>the read or write routines.
Correct. Binary is what should usually be used, unless actually dealing with
text files.
>It might be fun to code a routine to compact the file in place.
>That is, you could rearrange the file such that all deleted records
>are placed after all the data records, without coping to a second file.
Or purging all the deleted records....
