On Jan 27, 5:53 am, "David Cressey" wrote:
"Brian Selzer" wrote in message

Well, that's just dumb. Checks in code can reduce database round-trips,
and
therefore can improve performance, but are not and cannot be a substitute
for constraints on the tables. It is the constraints on the tables that
keeps garbage out of the database.

The idea of keeping garbage out of the database takes on an entirely
different meaning if you are dealing with hundreds of programs written in
COBOL, Java, or anything in between accessing a single Oracle database on
the one hand. On the other hand, if you are a developer creating a self
contained MS Access database cum application (tables, queries, forms,
reports, modules, etc.) all in one file, the same issues arise, but they
are resolved quite differently.

I'm not saying either one is "right" or "wrong". I'm just suggesting why an
objection that makes perfect sense to you and me might be lost on the MS
Access community.

There's another approach to enforcing constraints: just tell your
users not to do that. In the hierarchy of what works, it comes
below checks in client code, but above manually inserting
garbage at design-time. It also has the advantage of being
even lower performance overhead for the software. Note
that centrally enforced declarative integrity constraints
are an endpoint in this hierarchy.


Marshall