Lek Olof

+ Follow
since Jan 03, 2007
Merit badge: grant badges
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Lek Olof

I want to make the choice that skip reading the magic cookievalue and the schema description part and just assume I have one table with the specified fields and field lengths and that these will never change in name or size.

This way the reading part would be much easier but then I would lose the option to rename fields and sizes in the schema part. For those who is building up the databse dynamically according to the schema part the solution has more advantage but I want to keep the solution simple as possible,

do you lose points if you disregard the schema information?

thanks for the help, I think I understand how to solve it now!


I was puzzled with following:

I have a RandonAccesFile on the server side which has the access to the db file. Before updating a record I lock it with the lock(int recNo) method.

But what happens when I update a record and the same time another client wants to read some other record and a third record wants at the same time update another record. Since the RandomAccessFile is (and should be??!!) on the server side it has only one file pointer so even if a lock a record to make sure nobody works with that record I still have problems.

If a synchronize the access to the RandomAccessFile there is no point in locking a record it seems since no multiple reads or writes to different records will be possible.

How have you guys solved this issue?


I just want to hear what your recommendation is regarding reading the file.

Are you reading everything, like the byte that says number of fields and fieldnames and all of that or are you hardcoding field names and number of fields in each record?

And what about that magic cookie value? are you just reading it and hardcoding like "if(magicCookieValue = 1234) then the file format is ok, else not ok?


Ok I understand.

So what are you guys mapping the recNo to?

I guess you have some kind of map where you map the recNo to some kind of clientnumber? Or what object to do map the recNo to?

When using the

public long lock(int recNo) throws RecordNotFoundException {

method of B&S assignemnt the assignment says that it should return a cookie value.

Can the recNo be the cookievalue, and if not, why?

I have been reading the search criteria discussion here on the forum but still I am confused.

The following condition each seperatly read is crystal clear:
- It must allow the user to search the data for all records, or for records where the name and/or location fields exactly match values specified by the user.

- Field n in the database file is described by
criteria[n]. A null value in criteria[n] matches any field
value. A non-null value in criteria[n] matches any field
value that begins with criteria[n]. (For example, "Fred"
matches "Fred" or "Freddy".)

But when I try to put them together I am a bit confused. I was testing the following case when I got confused. For example the record:

Freddy Boston

If I search with empty fields, this record will be found. How about searching with the following conditions, should the above record be found in each of the following cases?

1. Fred Boston
2. Fred Bos
3. Freddy Boston (of course it should be found here but I just want to point out that I think there is a difference in these 3 searh conditions)

thanks in advance!
Barry -> thanks for the reply.

I understand what you mean. What seems strange to me is the following interface method decleration:

public String[] read(int recNo)

this method should be used by the GUI to retreive a record. But how can the search criteria be an int recNo??? The "only" search criteria should be some string with location, city etc or drop downs menus etc.


I am doing the Bodgitt and Scarper assignment. My question is that recNo in the database interface seems to be a unique identifier for a record in the database.

But what is int recNo, what field does it correspond to in the database schema? The answer is so obvious that I cannot figure it out =)

Required Interface
Your data access class must be called "Data.java", must be in a package called "suncertify.db", and must implement the following interface:

package suncertify.db;
public interface DB
// Reads a record from the file. Returns an array where each
// element is a record value.
public String[] read(int recNo) throws RecordNotFoundException;
// Modifies the fields of a record. The new value for field n
// appears in data[n]. Throws SecurityException
// if the record is locked with a cookie other than lockCookie.
public void update(int recNo, String[] data, long lockCookie)
throws RecordNotFoundException, SecurityException;
// 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 delete(int recNo, long lockCookie)

And the database schema:

The database that Bodgitt and Scarper uses contains the following fields:
Field descriptive name Database field name Field length Detailed description
Subcontractor Name name 32 The name of the subcontractor this record relates to.
City location 64 The locality in which this contractor works
Types of work performed specialties 64 Comma separated list of types of work this contractor can perform.
Number of staff in organization size 6 The number of workers available when this record is booked
Hourly charge rate 8 Charge per hour for the subcontractor. This field includes the currency symbol
Customer holding this record owner 8 The id value (an 8 digit number) of the customer who has booked this. Note that for this application, you should assume that customers and CSRs know their customer ids. The system you are writing does not interact with these numbers, rather it simply records them. If this field is all blanks, the record is available for sale.