What is acceptable error trapping?

  • Thread starter Thread starter Frederick Wilson
  • Start date Start date
F

Frederick Wilson

I was just reading another post and it was recommended to keep from
getting duplicates in a field to set that field property Index to Yes,
no dups. If you enter a dup then and error is generated. Trap this error
and display a custom message.

Is this the normal way of doing things? Or is it an acceptable way?

I have no real preference on way or another. I am not school trained and
a lot of what I do is self taught via trial and error. And of course
input from here.

Thanks,
Fred
 
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
 
Back
Top