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.
Duh, why didn't I think of that?!!! Excellent suggestion. Thank you.
>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.
Hmmm. I'm not sure if that would be a good thing or a bad thing... I'll
get back to you on that one.
>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.
Yes, and I started out opening files in binary mode, but I was having
all kinds of trouble with file positioning. For some reason, switching
to ASCII mode seemed to solve it. Perhaps it's time for another try.
**P.S. to Ralf, I tried to respond to your reply to the Listserv two days
ago, and I got a message back this morning saying it hadn't gone through.
Sorry**
>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....
>Indexing comes to mind, also.
That's the reason I've reserved a full 1,024 bytes for the header, and the
mysterious 12-byte reserved area as well (8.3 filenames). So far, I haven't
thought up
a way to make an indexed file that's faster than seqential reads. Once
I (or someone else) works that part out, I definitely want to add indexing!
I like the theory behind "linked lists" in C and C--. I'm thinking of something
along the same lines for an indexing method.
>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.
But we wouldn't want to do this if we were going to UNDELETE records...
( yeah, I know - cop out, but I do have a point 
>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.
Perhaps reformat is ready for v 2.0?
Brian Jackson
Programmer/Analyst
Printing, Inc
(316) 265-1201 x 225
www.printinginc.com
|
Not Categorized, Please Help
|
|
