On Tue, 28 Mar 2006, dillon_at_SpamMinuSaccessdenied.darktech.org wrote:
> Hi,
>
> What is the norm when a front-end programmer (e.g VB) designs an
> interface for a database (e.g Oracle)?
>
> Specifically, I mean should the front-end programmer hard-code
> constraints like null/nullable fields into his/her interface, or
> should he/she just output the meaningless Oracle errors to the user?
> (e.g via the VB interface).
>
> I was thinking there are good and bad things about the front-end
> programmer hard-coding/duplicating the "controls" into their program.
>
> The bad: if the DBA un-nulls a field on the Oracle DB, the front-end
> will still insist on a input of data for that field. The DBA must tell
> the programmer to do some re-coding and re-compile the front-end.
>
> The Good: if certain fields need to be unnulled (e.g for some
> data-migration), it will not affect the front-end. That means
> data-entry staff can continue to data-entry and all the "checks" will
> still in be place.
>
> So what is the norm?
It should be in both places really. The database design will protect
the integrity of the data, but the software should understand the
constraints of the database and be proactive instead of getting errors
from constraints and react. A nice way for the front-end to accomplish
this is to define the constraints in the application at compile-time by
reading the database's meta-data.
--
Galen Boyer
Received on Wed Mar 29 2006 - 23:05:03 CST
