My feeling is that people seem to be locking on record number. Has anyone done it on the flight number, instead? Since, it is the PK, it will always be unique even in the unlikely case of merging databases. I think locking on flight number is superior because you do not need to keep any map of flight no (returned by the gui) to rec. no. The idea is that you don't want to find the corresponding record no of the given flight number in the booking method. Just curious, what do people think? Alex
i personally like record number because it is purely numeric, not alphanumeric. Also, it is more intuitive since datastructres like hashtables usually accept Integers for keys, not Strings. But thats my 2 pennies, i dont know the right answer.
Some of Sun's Data methods acts like flight number is unique, but I think that is a flaw in their code. In real life, airlines have the same flight number on different days, so there would be duplicates. I would stick to using record number in your code, don't change Sun's code, and document the problem.
Robin, But if you look at the flight number in the file, the airline is part of the string - the first two letters. If you decided to lock on record number, did you keep a hashtable with key: flight number and value: record number somewhere in your code? Alex
No, I didn't break apart the flight number string. Record number should be the unique value. There's no reason to think that flight number would be unique, other than that it happens to be unique in Sun's db.db file. In real life, airlines seem to use the flight number to identify regulary scheduled flights. The flight number isn't unique even for the same airline.
snakes are really good at eating slugs. And you wouldn't think it, but so are tiny ads: