Hi,

Error trapping is a bit like 'closing the doors after the horse has bolted',
my personal belief is well written code does not require much in the way of
error trapping because the logic of the code enforces business rules, e.g.
why wait until writing the record to get a null error in a field when before
the update of the record you are checking for null or empty fields in code
and reporting back to the user before a real error occurs.

In your specific instance I would check the 'on change' or the 'lost focus'
event for the specific field and run some code to validate the field,
a select statement like

select count(*) as Total from TblTest Where First_Name='" &
me.txtFirst_Name.Value & "' and myPrimaryKey <> " &
me.txtMy_Primary_Key_On_The_Form.Value

and making sure that the total value = 0 (good)

Hope that helps.

There's no one-size-fits-all answer to this, Fred. If you are developing an
internal tool to be used by yourself and a small number of colleagues who
work closely together, you don't need the same level of bullet-proofing that
might be required if you're developing a commercial app that will be
deployed to multiple customers at widely-dispersed locations.

Take your example of duplicate values. If I were developing an internal
tool, and if the users were people who would understand what the default
error message meant, I might just let Access handle it. If I were developing
a commercial app, I'd probably do my own checking for duplicates in the
BeforeUpdate event procedure.

Just as I figured, two sides of the same coin. Thanks for the replys. I
am kind of anal about clean and neat things. I tend to agree to trap the
 error before it happens, in other words, checking for nulls and
duplicates and such.

Thanks again,
Fred