When in report caster, the following code is returning an invalid date. When running in MR Dashboard, it's returning correct date value. Does anyone know what could be the problem?

-DEFAULT &ENTER_FROM = '04/01/2009'; //Julian date of this is 109091
-***********************************************************************
-* GET THE CURRENT JULIAN DATE USING GETSALESDATE FUNCTION.
-* IT USES THE &ENTERED_DATE PARAMETER.
-SET &ENTERED_DATE = &ENTER_FROM;
-INCLUDE app/getsalesdate
-IF &LINES EQ 0 THEN GOTO THEEND;
-SET &JUL_FROM= &PDATEJUL; //&PDATEJUL is a value return from getsalesdate.fex
-***********************************************************************
-SET &_FROM_GREG = GREGDT(&JUL_FROM, 'I8YYMD');
-SET &_TEMP_FROM = DATECVT(DATEADD(DATECVT(&_FROM_GREG,'I8YYMD','YYMD'), 'Y', -1), 'YYMD', 'I8YYMD');
-SET &_JUL_PREVFROM = JULDAT(&_TEMP_FROM, 'I7');
-***********************************************************************

This is the log from report caster:
-SET &_FROM_GREG = GREGDT( 109091, I8YYMD );
-SET &_TEMP_FROM = DATECVT(DATEADD(DATECVT(1090401, I8YYMD , YYMD ), Y , -1), YYMD , I8YYMD );
-SET &_JUL_PREVFROM = JULDAT(19001231, I7 ); //in MR dashboard, 19001231 should've been 1080401

This job runs daily in RC. Occasionally, the date function didn't work in RC. However, it works 100% of the time when running in MR dashboard. Any inputs would be greatly appreciated.

Many thanks,

This message has been edited. Last edited by: Kerry,

quote:

-SET &_FROM_GREG = GREGDT( 109091, I8YYMD );

Shirley,

I guess this is meant to be a julian date but what is it meant to be (value wise) 2009091? (=1st April 2009). This value is being interpretted as 1090401 as an I8YYMD value (=1st April 109) which is way off the radar and is causing the return from your DATECVT(DATEADD combo to be a zero (invalid output). This in turn is interpretted as being 0 days from the base date which is 31/12/1900.

I cannot understand why this would have ever worked with a value such as 1090401 being passed to the DATECVT function as an I8YYMD.

I would suggest re-evaluating the data you are using for dates and ensure you use full year containers (after all, that was what caused the stir for Year 2000!).

T

The problem seems to arise in getsalesdate, which apparently (judging from the reference to &LINES) uses some Define and Table and finally -READ to set the & vars. If you post it, perhaps we can spot the issue. (Perhaps a data file it references, or its .mas file, differs in RC from that accessible in Dashboard)

The problem is a 6-digit Julian date, which is usually 5 or 7, with the 1st byte denoting the century:

 
-SET &JUL_FROM  = 109091;
-SET &CC1       = EDIT(&JUL_FROM,'9');
-SET &CC2       = DECODE &CC1 ( 0 '19' 1 '20' ELSE '21');
-SET &CC3       = &CC2 || EDIT(&JUL_FROM,'$99999');
-SET &FROM_GREG = GREGDT(&CC3, 'I8YYMD');
-TYPE &FROM_GREG
-EXIT

Or simplify it;
-SET &JUL_FROM = 109091;
-SET &JUL_FR=&JUL_FROM +1900000;
-SET &FROM_GREG = GREGDT(&JUL_FR, 'I8YYMD');
-TYPE &FROM_GREG

I've updated the program to use 7 digit julian dates. I had to convert back to six digit julian date because that's the value in our system, which it's needed for whereclause. It's better performance this way rather than using the define field for whereclause.

Thank you all for the respond. I'll find out tomorrow if it works.

Regards,

Shirley:

Do you have an explanation why this code behaves differently "when running in MR Dashboard"?