At 08:04 AM 10/11/95 -0700, Duane Percox (Quintessential School Systems) wrote:
>> 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##).
Most report writers and data extraction tools (such as our DataExpress
product) provide for the ability to extract a "substring" of the contents of
a field.  In addition, we provide the ability to create new fields that can
be made up of data from other fields (or parts thereof, or manufactured from
constants).  This usually allows the user to perform whatever "re-arranging"
[s]he requires.  In our case, we also provide the ability to store these
computed items within views and procedures so that they do not have to be
re-specified repeatedly.
 
>
>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.
It is our position at M.B. Foster that yes, indeed, the reporting and data
extraction tools must provide for the multiplicity of ways that users might
design and structure their data storage.  We consider that ability to be one
of our strengths and a differentiator between us and at least some of our
competitors.  Not only do we provide mechanisms for computing temporary
items from one or more actual data items, but we also have the provision to
describe the data both by it's storage attributes as well as it's logical
attributes.  In the case of dates, we provide for a multitude of date
formats (Birket says more than 16 but if you take the combinations it is
probably more) that include the popular application date formats (ASK and
Cognos for example) as well as the CALENDAR [yy]yymmdd mmddyy[yy] ddmmyy[yy]
[yy]yyddd and most other combinations that have been mentioned in this thread.
 
>
>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.
 
YES! YES! YES!
 
<PLUG>
DataExpress, M.B. Foster Associates Limited  1-800-ANSWERS
</PLUG>
 
Brian Duncombe ([log in to unmask]) - M.B. Foster Software Labs
"Inside every large program is a small one struggling to get out."
          C. A. R. Hoare