Hello All,

I need to check if an amper variable has data to it or not.
I have some reports which are scheduled monthly and they can also be run by users at their convenience (to get historical data).
The reports need begin date and end date as parameters.
I have calculated the begin date and the end date of the current month using the &MDYY command and am feeding these values as input to the
where conditions.
As the reports are run monthly, the report caster job is working fine.

However my users also want to run these reports at their convenience from a launch page (occasionally).
When they give a historical begin and end date, they are being overwritten by the calculated begin and end dates and the report is not running for the desired months.

Is there a way so that when the users run the report, the report picks the dates given by them and if no input is provided, picks the calculated begin and end dates.

Any suggestions will be helpful.


Thanks for reading.

Sumant

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

-SET &calculated_start_date=(whatever);

-DEFAULT &date_parameter=&calculated_start_date.EVAL;

-SET &date_parameter=&date_parameter;

If user supplied a value for &date_parameter, it sails through the -DEFAULT statement unchanged. If not, the calculated 'default' values gets assigned. The -SET ensures that &date_parameter will be impervious to any -DEFAULT encountered downstream, perhaps within a -INCLUDE

Take a look at the .EXIST suffix. It may be helpful in this instance.

Thanks a lot j.gross and jimster06 for your suggestions.
Will implement them.

Thanks,
Sumant

Hello,

I tried the method suggested by j.gross.
However when prompted, the string &calculated_start_date.EVAL is being printed.
The date should be printed but the exact string is being printed here.
I am coding in MRE and tried a few other examples. I cant DEFAULT to an &variable.



Thanks,
Sumant

Works for me.

program1:

-SET &date_parameter=20120817;
-INCLUDE app/program2.fex

program2:

-SET &calculated_start_date=20110327;
-DEFAULT &date_parameter=&calculated_start_date.EVAL;
-TYPE &date_parameter

Hello Francis,

In your suggestion, the user's date wil always trump the calculated date.
The BOM and EOM dates have already been calculated using system date and are being used as input to the where clauses.
If the users want to input their dates, the where clauses should pick the user's dates else pick the already calculated BOM and EOM dates.

Thanks,
Sumant

That's what I tried to illustrate. If you comment out the -SET command in program1, the default will be used.

Hello Francis,

When I comment the -SET command in prgram 1 and run it, the text "&calculated_start_date.EVAL" is being printed instead of the date given in program 2.
I was going through some old posts in this forum, and saw a post similar to this which said the -DEFAULT does not work well in MRE.

When I run the same procedure in Data Servers, it works absolutely fine.

Thanks,
Sumant

Works for me in MRE (this is the ECHO=ALL result):

 
-*-SET &date_parameter=20120817
-INCLUDE dummy2

-SET &calculated_start_date=20110327;
-DEFAULT &date_parameter=20110327;
-TYPE 20110327
20110327

These code examples work for me on MRE as well. Here they are in the context of GGSALES

 -SET &RC_START_DATE='19960101';
-SET &RC_END_DATE='19961231';
-DEFAULT &START_DATE=&RC_START_DATE;
-DEFAULT &END_DATE=&RC_END_DATE;
-SET &START_DATE=&START_DATE;
-SET &END_DATE=&END_DATE;

TABLE FILE GGSALES
SUM 
     GGSALES.SALES01.DOLLARS
BY  LOWEST GGSALES.SALES01.DATE
WHERE ( GGSALES.SALES01.DATE GE &START_DATE.EVAL ) AND ( GGSALES.SALES01.DATE LE &END_DATE.EVAL );
ON TABLE NOTOTAL
ON TABLE PCHOLD FORMAT HTML
END 

You could also do something goofy like this, if you don't trust DEFAULT.

The below example just checks to see if there is already a value for the date parameters. It's not as elegant as using DEFAULT.

[CODE]
-SET &START_DATE=IF &START_DATE EQ '' THEN 19960101 ELSE &START_DATE;
-SET &END_DATE=IF &END_DATE EQ '' THEN 19961031 ELSE &END_DATE;
[CODE]

Similarly, you could try to determine if the report was coming from MRE, and, if so, ignore the calculated values.

This post lays out a test like that.

Thanks ND and Francis for your replies.
I will implement ND's method and let you know.


Thanks,
Sumant