Open the SampleJdbcDAO class. This is a DAO that uses JDBC for storing/retrieving Sample objects in the Sample table.

Take a look at the addSample method --- specifically lines 31--33.

Note that there is some additional work that needs to be done to convert the LocaleDate and LocaleTime objects that the Sample class is using into SQL Date and Time objects.

Note what is required to extract the scientistNum from a Sample object. Refer to the class diagram:

{{/Labs/07/Diagrams/Class Diagram}}

The Sample class does not have a scientistNum, but it does have a reference to a Scientist --- we can follow the reference (by calling the getScientist method on the sample) and get the scientistNum from the sample's Scientist object.

Take a look at line 39.

JDBC has terrible exceptions --- there is basically just a generic "Whoopsy --- bad things happened" exception (otherwise known as SQLException). If we want to catch errors that the user could easily trigger, such as primary key or check constraint violations so that we can tell the user what they did wrong, then we need to examine the message contained within the exception.

You can see now why we insisted that you use named constraints when adding constraints to a table. We can look for the constraint name when handling the error. In this case we look for sample_pk which is the name of the primary key constraint in the Sample table (look at <> to verify this) --- if we see that string appear in an exception then we know that the user has entered the same sample twice.