RE: Month, day, year fields

Actually, stored procedures are about midway on my list.  Personally, I
prefer message-based servers - stick an XML wrapper on it and you've got
a web service, wrap a procedure around it you've got JDBC/ODBC access.
But once again, that's primarily for data entry/validation.

For queries, just about anything that makes sense for your business is
okay by me.  There are inherent problems with SQL (and thus JDBC and
ODBC), especially when you allow users direct access to tables rather
than views, but at that point it's a business decision.  Just don't
complain to me when you have to rename a field and 800 user-written
Excel spreadsheets go casters up.

But what I absolutely LOATHE is update-capable ODBC access to the
database.  Letting a client program update your database directly is
like allowing direct Internet access to a Windows server.  It *MAY* not
cause problems, but nobody in their right mind does it on purpose.  And
shoving half of your business logic into a trigger is not the answer; it
just spreads the code.  Have one server that owns the file and be done
with it.

Joe

> From: rob@xxxxxxxxx
> 
> Actually Joe I thought you were a big fan of stored procedures.  You
know,
> externalizing I/O and all that rot, versus having the program on the
> client directly access the data via jdbc/odbc calls.