HP3000-L Archives

October 1995, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Duane Percox <[log in to unmask]>
Reply To:
Duane Percox <[log in to unmask]>
Date:
Wed, 11 Oct 1995 08:04:02 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (36 lines)
> Wirt writes:
>
> [snipped...]
>
>There is almost no simple way for the great majority of report writers in
>existence to extract the middle two digits out of a numeric value such as
>940501, especially when you wish to sum all of May data for the last 10
>years, regardless of year or day value (##05##).
>
 
I don't want to debate the issue of text vs numeric for dates, but I would
like to comment on this particular point of Wirt's message.
 
Respectively I ask: Why not?  I think the folks who write report writers
should be able to do this. You don't always get to control the format of the
database you might be reporting against, so it would be a real shame to have
to depend on a tool that wasn't robust enough to do the conversion
automatically.
 
If I tell my reporting/extract tool that a field is a date of format yymmdd
or yyyymmdd I shouldn't have to care how it is stored in the database. The
tool should take care of it, convert it to a fixed size and then allow
subfield use.
 
<soapbox>
The databases came first. Then the report writers. The authors of the report
writers should be turning out tools that address the needs of the users. The
users of the report writers shouldn't have to adapt to the limitations of
the report writers.
</soapbox>
 
 
-- Duane Percox (Quintessential School Systems)
   [log in to unmask]  | www: www.aimnet.com/~qssnet/
                  | ftp: ftp.aimnet.com/pub/users/qssnet/

ATOM RSS1 RSS2