Hi Kaspar
1. What's the point of the "date" field if it's in the past (e.g. 2004)? Do I simply ignore them in the booking or should I allow booking of available rooms which are in the past (which wouldn't make sense for a real-world application)?
I have seen some candidates talking about having an option at startup time that will allow access to records that are outside the date range. Others simply ignore dates outside of range.
2. What about the 48h rule? I this must be followed strictly, it means that the application cannot be tested unless the current date is really within 48h of the free room date.
There have been quite a few candiates that have failed for not implementing a check on bookings outside of 48 hours (however the 48 hour "rule" is not a "must" requirement, so they seem to pass on appeal). Regardless, I think it is a good idea to implement the rule, and it will be up to the assessor to ensure that they have valid data.
3. As far as I can tell by reading Sun's requirements, the CSRs want to search for records and possibly book some of them. Now if a room gets booked, what happens afterwards? Shall it automatically get unbooked after one day? Shall the CSR be able to unbook it manually? The specs don't say anything about this - but when I don't implement any unbooking functionality, the database will get gradually filled up (i.e. records get booked) until the database is full and the application cannot be used anymore as no more bookable rooms are avialable anymore. Not very useful for a real-world application.
I don't think the instructions mention anything about unbooking (either automatically or manually). However the instructions do say that you wont get extra marks for going beyond the instructions
. So I wouldnt worry about it.
Regards, Andrew