chris bajada

Apart from:
1. Bugging me with private messages to send you the specifications which sun gave me
2. Asking me privately to send you the work which I had submitted to SUN
3. Repeating the same stupid questions in the forum

I really suggest you use this forum's Search feature to search for topics if you want any help, as the question you are asking has been answered repeatedly.

What I have done in my case is:

1. The application tries to connect on the current settings provided by the suncertify.properties file.

2. If the application connects - no settings dialog is shown.

3. If some exception is generated, the settings dialog is shown so that the user enters correct settings (such as a correct server IP address).

4. If the application connects as described in (2) and the user did not really want to connect to this server, he can access the settings through the GUI and connect to another server using different settings.

Futher to Jeroen T Wenting's post- I did not submit the suncertify.properties file ( i don't actually think it has to be submitted). The file is created automatically if it is not found. Then the settings dialog is automatically shown upon startup (as with empty settings the application can't connect). Then once correct settings are entered, the asessor can use the application how much he likes without entering the settings again, provided that the server is still online on the same IP and on the same port.
[ July 08, 2007: Message edited by: chris bajada ]

Does it mean the class which must implement this interface is the one manipulating database I/O, at the file level?

Yes.

You have to provide intermediate classes that use this data access class. (between the gui and this Data access class). In the local client (stand alone client), this intermediate class would call the methods of the data.java class directly (as the db file is on the same machine), but when the client is in networked mode, the calls from the gui have to be passed on to the server over sockets/rmi.

The server will then execute the request using his data.java class.

cheers,
chris

in the integral7 database, if you go to the history section- it shows that the exam is pending.

I'm waiting here too...

Well however strictly speaking, if the application (or test) happens to try and delete a record which is already deleted... nothing weird would happen - just the deleted flag would be overwritten with the same deleted flag, so I do not think that we really need to worry so much about this.

Cool! You deserve it!

In my case i am also throwing RecordNotFoundException when the record is deleted. Thus if anyone is following my scenario- it would be simpler just to call a 'readrecord(recno);'
in the delete method. This would throw a RecordNotFoundException if the record to be deleted is already deleted, which would then be handled at upper levels.

Thus in this way the only part in the code where you check for the deleted flag is in the readrecord method

Erkin, I don't really think you need to cater for that scenario... look out as if you do something like that, it might fail their automatic test

Hi Mandy,

I have just done B&S. What the assignment states there is that your findByCriteria() method should return those records which "A non-null value in criteria[n] matches any field value that begins with criteria[n]". (fred matches freddy)

However that is telling you that before the search results are sent to the GUI class to show them in the JTable, you need to re-filter them for those records which EXACTLY match the user's request.

I.e. GUI.java - MiddleClass.java - Data.java - DBFile

Data.java gets parital matching records from dbfile and passes them to your middleclass. The middleclass re-filters those results and passes only those records exactly matching the user's request to the GUI.

That's how it should be done. The middleclass i portrayed there should be the client class which performs the logic and calls the data.java methods

Otoh - if you're spending $150 of your own money

price gone up to $200 recently

As regards the DuplicateKeyException - my program does not allow the creation of a record which is exactly the same as a record which already exists, as it is confusing for the user if 2 records which are exactly the same show up in the GUI.

When reading deleted records, RecordNotFoundExceptions should be thrown.

Thus when your search mechanism is looping through the dbfile, it will check out only those records which do not throw that exception.

I have the B&S assignment, same here - it did not say anything about deleting records, but my Data.java has to provide the mechanism to delete these records. What I did is I implemented it in my UI and client/server communication for testing, and then deleted it before submitting; leaving it only in the Data.java class.

Rest assured that all the methods in the interface have to be implemented.

I'm currently awaiting response from a local prometric centre... hope to get done soon,

good luck mate

chris

My experience with Sun and Prometric are both A+ (so far). My time to wait for the upload rights were just 2 hours after I sent the email, and it was during the evening.

After I this thread I sent a mail to suncert@thomson, and suncert@prometric and they replied to both of my mails and I finally submitted.

Time to fix an appointment with the local prometric centre here now...

Thanks for your replies. Padding with leading zeros seems a pretty good idea to keep all numbers in the same format, I think i'll do the same.

Cheers,

Chris

Hi,

I was wondering whether the customer ID of the B&S assignment should be strictly 8 digits, or if you can enter a number with less then 8 digits such as "42".

The assignment states that the owner of the record is an "id value (an 8 digit number)"

Any comments on this ?

Thanks!