Now if the person with the application with the original view of the database file attempts to book he will be booking a different record to what he believes he is booking? Does anybody know how to deal with this issue. Is it just a matter of giving each new record a unique number? Any help on this would be much appreciated. Thanks guys.
1. You should not care about this stuff unless you have requirement to implement delete function (say, on server side). Delete may be mentioned in interface (as in my URLyBird) but I had no word that I really have to use 'delete' button in GUI. I implemented this method but did not use it.
2. One way to handle this kind of problems is to make server which lets clients know that some record(s) was deleted. It can be done with RMI, say, you observer which waits if any records are deleted and calls corresponding 'refresh' method on clients. But, in this case it is overkill, because this feature is not required by Sun and therefore may only lower your grade. And it is also not good because decreases prformance.
3. You may consider following : let users see dirty records, but when user tries to book record, additionally check on server tier if that record has been deleted already.
The way I am dealing with this is that in Data's update method, I check the primary key to make sure that it is updating the right record. When the primary key does not match, a RecordNotFoundException is thrown. And I explained this in my choice.txt file. (I even thought when this kind of exception get caught by the client, to force the client do a refresh of the listed records, but later figured it is not necessary for this assignment)
Originally posted by Bing Yuen: The way I am dealing with this is that in Data's update method, I check the primary key to make sure that it is updating the right record. When the primary key does not match, a RecordNotFoundException is thrown. And I explained this in my choice.txt file.
Bing, Instead of comparing only the primary key, maybe comparing the whole record could be better?
Vishwa, I thougt about comparing the whole record but can not get rid of my first instinct of using the primary key. As I stated in my choice.txt this sounds more logical as the primary key being the only credential to identify a record in database. Comparing the whole record is somehow degrading the power of having a primary key constrain. Plus, what if there are too many fields( I don't know how many is "too many", but you know what I mean) in the record? It sounds exausting to compare them all.
(Edited to add one more point I meant to mention) The create method in Data will check the primary key too for duplicate record, so there should be no two records have the same key combinations and this guarantee that the update will occurr to the right record after making comparison on primary key.