NX: Some question about access db.db

[Wu Ming]

I am the first time to come here. Now, I am prepare for the URLyBird.
Here is the information about the data format:
*****************************************************************
Data file Format
The format of data in the database file is as follows:
Start of file
4 byte numeric, magic cookie value. Identifies this as a data file
4 byte numeric, total overall length in bytes of each record
2 byte numeric, number of fields in each record
Schema description section.
Repeated for each field in a record:
2 byte numeric, length in bytes of field name
n bytes (defined by previous entry), field name
2 byte numeric, field length in bytes
end of repeating block
Data section.
Repeat to end of file:
1 byte "deleted" flag. 0 implies valid record, 1 implies deleted record
Record containing fields in order specified in schema section, no separators between fields, each field fixed length at maximum specified in schema information
End of file
*******************************************************
**********************************************************
// Deletes a record, making the record number and associated disk
// storage available for reuse.
// Throws SecurityException if the record is locked with a cookie
// other than lockCookie.
public void deleteRecord(long recNo, long lockCookie)
throws RecordNotFoundException, SecurityException;
**********************************************************
I have some questions about the data.
1. Do I need to Identifie the value of 'magic cookie value' at the beginning to access db.db?
2. There is no data of the number of records in the data, do I have to count the number of record one by one?
3. If delete a record, do I just turn the flag of Record from 1 to 0?
3X.

[George Marinkovich]

Hi Wu,
The magic cookie value:
Some people read this value, determine it's value, and then use this value to help validate the file. Others ignore this value entirely and do no validation of the magic cookie value. I think it's your choice; either decision is defensible. Obviously it's less work to ignore it, and since there's plenty of work ahead, that may be the most prudent course.
The number of records in the data file:
I think it's very useful to know the number of data records. One way to do this is to count the records when you process them as you suggested. There's another way based on the length of the file and knowledge of the data file format given in the assignment instructions. I don't know that one way is better than the other, they will both work.
Deleting a record (or rather marking a record for deletion to be more precise):
Yes, setting the validity bit to zero is sufficient.
Hope this helps,
George

[Javini Javono]

Hi,

1. Do I need to Identifie the value of 'magic cookie value' at the beginning to access db.db?
2. There is no data of the number of records in the data, do I have to count the number of record one by one?
3. If delete a record, do I just turn the flag of Record from 1 to 0?

Probable answer for 1: The magic cookie value tells your application that the file
you are reading is of the correct format. That is, the file is your company's database
file instead of a JPEG file, for example. If the file's magic cookie value is not as
expected, then you probably can safely feel free not to read it (you may also post
a message to the user, et cetera); actually, you probably should not continue
to attempt to read the file. If the file's magic cookie value is correct, it is
highly likely that the file is the company's database file that your program has been
written to process. [aside: an interesting test case I might add to my notes is
when the file is "junk" but the cookie value is correct; highly unlikely, but my
software should handle this situation without blowing up].
Probable answer for 2: You could count the records one by one, but if you compute
the physical size of each record in bytes, and you determine the length of the
non-header portion of the file (by requesting of your file object to return its
length and then subtracting the number of bytes in the header), division will
yield the number of records in the file (assuming the file is not corrupted).
Probable answer for 3: That might depend on your implementation (for instance,
when you delete the record by making it inactive, you might also erase all the
logical data in the record if doing so logically supports a logical point in your
design). But ignoring implementation for now, then conceptually, if the
record is inactive, then it is deleted, and any logical data still resident
in the file (such as name, address, zip, or what have you) for
that particular record is considered not to exist in the database.
Similarly on older computers, when you erase a file, the
operating system simply removes a pointer to your file and your
file is considered to have been deleted (but still, the contents of your file still
reside on the disk ready to be written over by another file in the future).
Aside: One of the first things I did, not being a file i/o expert, was to write a
file validator; this got my muscles initially flexed and put a little file i/o experience
under my belt. Then, I felt more at ease to start considering design issues.
Thanks,
Javini Javono
[ January 07, 2004: Message edited by: Javini Javono ]

[Wu Ming]

Thank you very much for your help.

[Jacques Bosch]

Hi Guys.

// Deletes a record, making the record number and associated disk
// storage available for reuse.

Does "available for reuse" mean available for reuse for this program, or for any program. I.e. Is it enough to leave the deleted rec in the file for possible reuse by my app? Or must the file be smaller when a rec has been deleted, giving the disk storage back to the OS?.
Thanx.
Jacques

[Wu Ming]

Originally posted by Javini Javono:

Probable answer for 2: You could count the records one by one, but if you compute
the physical size of each record in bytes, and you determine the length of the
non-header portion of the file (by requesting of your file object to return its
length and then subtracting the number of bytes in the header), division will
yield the number of records in the file (assuming the file is not corrupted).

Thank you for your help. I have another question about your answer. Do I have to deal with the problem when the number of records is not equal to the number you calculate by the length(such as file corrupted or other reason)? Because in real world, we will met a lot of problem when we do this. I dont know whether it will be ok or not in the scjd exam.
Thank you again.

[Wu Ming]

TWO MORE QUESTION:
1.
// Reads a record from the file. Returns an array where each
// element is a record value.
public String [] readRecord(long recNo)
I am confused with the 'recNo'.because there is no record number in the db.db and there may be some 'deleted' records in the db. Is this number the order number of the record in the db. for example, if the recNo=21, that is to say, it is the 21st record count from the 1st one(include some record set the flag to 'delete').
2.
public void updateRecord(long recNo, String[] data, long lockCookie)
throws RecordNotFoundException, SecurityException;
is the 'lockCookie' assigned by the server which connect the db and the client?

[Javini Javono]

Hi,

Thank you for your help. I have another question about your answer. Do I have to deal with the problem when the number of records is not equal to the number you calculate by the length(such as file corrupted or other reason)? Because in real world, we will met a lot of problem when we do this. I dont know whether it will be ok or not in the scjd exam.

I personally am not in a position to answer this questions as I have not gotten
to that level of implementation detail yet; but, as I make my first draft, your
question is certainly worth nothing and considering (as our design choices
have to explain what we considered). If I recall correctly, my verification
application checks that the division results in a double value with no significant remainder
[on second thought, it more than likely actually uses the modulo operator which
is safer],
as an example of one of the many checks it makes. Another possible verification,
though one I don't know right off whether I have used or am using, would be to
assert that the file is of a certain size (based upon how many active and inactive records
you think are in it) and compare how this matches up to the actual physical size
of the file; if they don't match up, then perhaps my theoretical software has made
a logic error somewhere.
thanks,
Javini Javono
[ January 08, 2004: Message edited by: Javini Javono ]

[Javini Javono]

Hi,

Does "available for reuse" mean available for reuse for this program, or for any program. I.e. Is it enough to leave the deleted rec in the file for possible reuse by my app? Or must the file be smaller when a rec has been deleted, giving the disk storage back to the OS?.

Available for re-use by your own application is what it means. It does not mean
giving back disk storage to the OS.
When I spoke of a file being deleted by the operating system, and how the
pointer to the file is removed, this was an example by anology. For normal
usage of your database file, it will not shrink in size; whether it will grow
in size depends on what you decide to implement or carry out.
thanks,
Javini Javono

[Javini Javono]

I am confused with the 'recNo'.because there is no record number in the db.db and there may be some 'deleted' records in the db. Is this number the order number of the record in the db. for example, if the recNo=21, that is to say, it is the 21st record count from the 1st one(include some record set the flag to 'delete').

There may be a mainstream group consensus opinion on this, but I'm not sure
exactly what it is; but, my own current thoughts are not mainstream, so no
need to mention them here (again). In general, I think that you have to come to
reasonable decisions about what will mean what so that your DBMain interface
makes sense. Perhaps others will reply so that I may read the mainstream opinion.
thanks,
Javini Javono

[Andrew Monkhouse]

Hi Wu,

I am confused with the 'recNo'.because there is no record number in the db.db and there may be some 'deleted' records in the db. Is this number the order number of the record in the db. for example, if the recNo=21, that is to say, it is the 21st record count from the 1st one(include some record set the flag to 'delete').

This sounds like a good way to calculate it.

public void updateRecord(long recNo, String[] data, long lockCookie)
throws RecordNotFoundException, SecurityException;
is the 'lockCookie' assigned by the server which connect the db and the client?

Yes - you should find that the lock() method returns a long value which is the cookie to be used in the update and unlock methods (and possibly others). So your server has to generate this number and return it to the client.
Regards, Andrew

[Terry Martinson]

Wu -
Check out this url and also the magic cookie one that is referred to in my post ( the 2nd one in this thread ). If you follow it all the way through, there is some sample test read code that might get you started.
Good luck.
TJ