Re: SQL Date function question

[Bradley Stone <bvstone@xxxxxxxxx>]

Totally understood, Rob.  And I've explained that.  A couple years ago
when I started this project I Saw those dates and said "WHOA!!!!".

The excuse, you guessed it.. "it's always been that way".

Brad

On Thu, Jul 7, 2011 at 9:32 AM,  <rob@xxxxxxxxx> wrote:
> Glad to hear you have it resolved.
>
> One advantage to using something like Alan Campin's iDate (or your own
> UDF) is that you can bury it into a view and not have to duplicate the
> date conversion into every query.  For example, if I do
> CREATE VIEW ECHL97 AS (SELECT idate(hedte,*CYMD) as OrdDate, ...
> Then in subsequent queries you can just shoot against that.
>
> The only problem is that the sort/select performance isn't as good as
> going against the raw date.  You know, the old
> select ... where hedte = ConvertDateToNumber(current date)
> will outperform
> select ... where ConvertNumberToDate(hedte) = current date
>
> But your lousy MMDDCCYY stored date is pretty worthless for
> sorting/selecting in any performance manner for any ranges.  Oh, it may be
> ok for one exact date but that's it.
>
>
> Rob Berendt
> --
> Group Dekko
> Dept 1600
> Mail to:  2505 Dekko Drive
>          Garrett, IN 46738
> Ship to:  Dock 108
>          6928N 400E
>          Kendallville, IN 46755
> http://www.dekko.com
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.