PH 8.19c2 Field Duplicate in Quick

[Mike Palandri]

At 05:00 PM 3/9/99 -0700, you wrote:
>Hi Everyone,
>
>I'm having a problem with field duplicating in quick (HP3000, v
>8.19c2).  I have a screen with the following:
>
>FILE TIME-SHEET PRIMARY OCCURS 8
>  ACCESS VIA EMP-ID      REQUEST EMP-ID OF TIME-SHEET
>  ACCESS VIA PROJECT-NBR REQUEST PROJECT-NBR OF TIME-SHEET
>
><snip>
>CLUSTER OCCURS WITH TIME-SHEET
>;
>FIELD PROJECT-NBR OF TIME-SHEET REQ &
>      LOOKUP ON PROJECT MESSAGE "This project number does not exist"
>FIELD JOB-CODE    OF TIME-SHEET DEF 'O' DUP
>FIELD DATE-T      OF TIME-SHEET &
>          default SYSDATE     &
>          duplicate           &
>          format MMDDYY separator '/' &
>          allow century
>CLUSTER
><snip>
>
>The Job-Code field is correctly duplicating from one occurrence of the
>cluster to the next, but the field DATE-T is not. If I enter 030999 for
>a date, the screen accepts it and formats it as "03/03/99", which is
>correct. On the next occurrence, if I press return to accept the
>duplicate process, I get an error that the field must be a date. I can't
>even type in the underscore ('_') to force duplication.  There are no
>user-defined procedures associated with either of the fields.
>
>Now for the _really_ wierd part. If I type in the date with slashes
>(03/09/99), the screen accepts it, and on the next occurrence, I don't
>get the error that the field must be a date, but the value that is
>inserted into the field by Quick is 03/09/91!
>

Hi, 

I have experienced something similar and I think it is normal PH behaviour.
I don't have the manuals with me, but I think that PH skips INPUT and EDIT
when it inserts a duplicate value.  Even if you have not explicitly coded
these procedures, at some point PH must change the entered value into a
date type, and this transformation appears to be skipped when the field is
duplicated.  Since PH stores dates internally in YYYYMMDD format, this
failure to format would cause PH to interpret 030999 as "Sept 99, '03" when
duplicated, which is not a valid date. 

Try entering "030309" and see if it still throws an error when duplicating.

If this turns out to be the problem, an alternative might be to enter the
date in YYYYMMDD or YYMMDD format or write procedural code to save the date
in PROCESS and stuff it into the field in INPUT if a zero length entry is
detected. There may be a better approach at the Cognos web site.



Mike