This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I was thinking about what feilds in the table that make up the primary key. Is it the contractor name??Is it the contractor name and the location together or other combination of feilds??
Another interesting thing which is: Whatever combination of feilds the primary key was,the question is:Why dont the update method throw a DuplicateKeyException.The update method takes an array of strings as the new value for the feilds.Thinking of the data access as a seperate module,it is possible that the update method will take parameters so that it would violate the primary key constraint.Note that the update method has void as a return type so there is no way for the client to know if the update operation succeeded or not.
What do you think about this issue and about the solution??
I personally don't think you can create a personal key from the database Sun has provided, which I believe has been done on purpose to make us think and document our decisions accordingly - I would recommend searching the Javaranch SCJD archives for "primary key" - I read many posts on this topic and with the knowledge gained looked at my spec again before making this decision (however, you may decide you need a primary key for your spec)
Of course throwing a DuplicateKeyException depends on whether you actually use a primary key, but again I would recommend searching the archives for this topic.
Whatever combination of feilds the primary key was,the question is:Why dont the update method throw a DuplicateKeyException.
Again this depends on whether you use a primary key - if you do you will probably want to prevent a client from changing data within a field used in the primary key in a pre-existing record. If you think about it, it doesn't make sense to alter or "update" the data which is being used as a primary key or you will in essence be creating a new record (i.e. new primary key = new record). If the user does want to alter the primary key, I believe they should be forced to delete the record and create a new one. If you follow this advice, you will never have to throw a DuplicateKeyException or return any value from the update method (as the recNo will always remain the same).
However, as I've said before, this is just my take on the problem, and searching through the Ranch archives may lead you to a different conclusion, but I'm always happy to discuss...
Daniel [ August 12, 2006: Message edited by: Daniel Bryant ]
I got also B&S. You do not need primary key. Create method, creates simply a new record, without checking for duplicates. No required � not done. In the worst case your search will return two the same records.