RE: Month, day, year fields

> From: rob@xxxxxxxxx
> 
> 3)  Data extraction works better with date fields than having to
either
> doing all that concatenating logic on the client or using a stored
> procedure to do so.  Not that I'm saying a stored procedure is a bad
idea
> versus direct data access (don't beat me Joe!).

<laughing>

Hey, Rob, I have nothing against stored procedures in an of themselves.
In fact, I have come to realize is that there are two distinct types of
programming tasks, data extraction and data entry/validation, and that
SQL and its various brethren are eminently suited for the former.  And
as tools are built that make it that much easier to build queries over
SQL tables, the more that the end user can own those sorts of
applications.  Except for some nagging issues having to do with security
and performance, this is actually a good thing.

I just knocked out a JavaServer Faces page in about 90 seconds using
WDSC.  I've yet to have the same success for anything beyond querying
SQL tables, but stick some UDFs in an SQL view and this thing is an end
user dream.

It's when people attempt to use SQL to write business logic that I get a
little nutty.  If which algorithm you use to calculate a value depends
on the settings of fields in two different files, SQL is NOT the
solution.  My guess is that in the next year or two we'll find that the
new "most inappropriately used programming syntax" is going to be the
SQL CASE statement.

Joe