Booking record via record number a bad idea?

[Steve Smith]

Hi all,

I have been thinking about the best way of booking records in URLyBIRD. At first I though I would use the record number. But thinking about it further this introduces a potential problem. If there is a record on screen and it is deleted on the database and a new record created, the new record can reuse the record number. So in theory if this occurs whilst someone is using the system, the user could be booking a completely different record to what they see. The record number stored can become associated with a different record.

Would it be better perhaps to use all database fields for booking instead of the record number? The problems I can think of with this are that its a bit less efficient and if two records are the same then the user could end up booking a different record number to the one they clicked if there are 2 records that container the same values for all fields. But then again, maybe this is not important if the records are essentially the same.

A third option could be to use the record number and also send the field's values through, and confirm the record has not changed before going ahead with the booking. What does everyone else think? Am I looking too much into this?

[Muthaiah Ramanathan]

Steve,

First - I don't allow any two records to be the same - when a record is created (or updated) it is checked for a match and if there is one I throw a DuplicateKeyException.

Just before I do a booking, I check if the record has been changed or not in the mean time (this check is done still in the GUI, because the GUI only knows what it had earlier).

Hope this helps.

Muthaiah.

[hatim osman]

Muthaiah Ram
Hi there...
I am interested on knowing how you were able to go about this:

First - I don't allow any two records to be the same - when a record is created (or updated) it is checked for a match and if there is one I throw a DuplicateKeyException.

As far as i know, most versions don't have an update() method that throws a DuplicateKeyException. It's a subject that has been discussed in many threads, however, it hasn't been clear to me untill now whether update() should allow duplicates or no. It's a very critical design issue, since it will have a major impact on booking implementation. How do you deny the updating of records that happened to have a duplicate key? I don't think that throwing an exception here is appropriate, many people chose to allow duplicate when updating.

Thanx in advance
Hatim

[Muthaiah Ramanathan]

Hatim,

Yes - my instructions also didnot mandate a duplicateKeyException for the update method. But since I'm not allowing to create one - I should as well stop the users from doing it via update. I wrap the DuplicateKeyException as a RuntimeException in the update method.

I check all the fields, except the Owner field, before throwing the DuplicateKeyException.

Regards,

Muthaiah.
[ October 14, 2005: Message edited by: Muthaiah Ram ]