Right Click on Parameters and select New.

Enter a parameter name, we'll call it "Date" here.

Choose the field data type of Date.

Save and close it.

In the Select Expert enter your formula using your new parameter:

What is the formula?

It appears you are not using this parameter date in the main report, only the sub report.

You can create the parameter in the main report without placing it in your select statement.

When you create your "Shared_Out_of_Stock_Date variable" jsut set it to  = {?date} parameter.

 

If this does not set it to ask for the parameter at run time just drop the {?Date} parameter field in your main report report header and suppress it.

 

 

I am a bit confused by how things are being used.  I understand that you are entering a date and you want all the items that will be projected to be out of stock on or before that date.  I think I have that right.

 

You have a formula in a subreport that does a calculation, but that is not real clear.  Is this what you were getting at:

local DateVar ReturnDate := Date (2099,12 ,31 );
Shared dateTimeVar Shared_Out_of_Stock_Date := ReturnDate;

if mailto:%7b@Monthly - {@Monthly Forecast} <> -1 then(
 Shared_Out_of_Stock_Date := CurrentDateTime + mailto:%7b@Monthly - {@Monthly Forecast} ;
 ReturnDate:=Date( CurrentDateTime + mailto:%7b@Monthly - {@Monthly Forecast}));
);
ReturnDate

Either way, you have this shared variable Shared_Out_of_Stock_Date being set in the subreport.  Here comes the big question...can you see this subreport?  Does the subreport do more than this, and if this item is to be 'in stock' should it be displayed?

 

why do I ask?  You are going to want to suppress something (and possibly this subreport) in the main report based on the variable Shared_Out_of_Stock_Date, and if you need to run the subreport before you can suppress the subreport, you are in a catch-22.  If the subreport is already suppressed, then life might be easier, depending on how the report is displayed, but as DBlank said, it doesn't appear that you are looking at the variable, you created it and set a value, but now what...

 

In the main report, create another formula:

shared datevar Shared_Out_of_Stock_Date;

 

this will display the results of the shared variable.  you can use it in suppression formula for a row, a field, or whatever you want to do with it.  Just remember that Crystal basically reads a report from top to bottom stopping to read subreports, so if the subreport is after the line you want to hide, you will have problems.

 

As always, if you got the data via a stored proc, you wouldn't need this as you could suppress the records from every making it to your report and the need of a subreport would go away...they are impose a lot more data reads to the database...1 is enough in the vast majority of instances...but the number of rows + 1 can really the impede the performance of your report.

 

Hope this made sense.

 

You should be able to set the shared variable to a parameter.  I would try a formula that assigned the parameter to the shared variable and place this new formula in the report header.  something like:

 

shared numbervar whatIwant := @parameter;

""   //to hide the assignment value

http://www.tek-tips.com/faqs.cfm?fid=1329

 

shared is shared, it has access to all parts of the report.  if you want to use it to select records for a stored proc or subreport, then I would create a formula that just 'displays' the shared variable and then use it in the linking of the subreport to the parameter that needs it.

 

I don't know if this work, but it is what I would try first...this is setting the parameter of the subreport to the value that you want.  I can't see why this wouldn't work, but Crystal has quirks, and I just might not have come across this one, yet.

shared numbervar whatIwant := @parameter;

""   //to hide the assignment value.
 and then use subreport links to link the main report and the subreport?

 

Does this make sense?

 

 

Sorry to lead you astray, again, I thought that the date was going to be generated from the data, not a parameter.

ReturnDate := {?Out of Stock Date}

 

This will assign the value of the field to the shared variable.

 

if you want to compare for the purposes of the selecting data:

if {some data field} >= ReturnDate then

 true //or false which ever is correct

else

 false //or true

 

This can shortened to just:

{some data field} <= ReturnDate

which can be used in filter or suppression formulas, but an assignment is the first example.

 

Given that you are going to use a SQL expression, you might not need to use the suppression, but it will all depend on what data is returned and what you want displayed.

 

shared variables are calculated by the report.  If you want to suppress something in a stored proc, just don't return it.  You can use a stored proc to return multiple tables and then use the value for one of the tables as a shared variable, but why?  Just use the value.

 

I do this in every report.  My stored proc returns 2 tables (sometimes more, but usually 2). 1 is the data for the report, 1 is the parameters used to generate the report (my data comes from an XML file...ok, ado.net really).  I will use the parameter information to, in some cases, to 'dynamically' structure/group my report.

 

As for suppressing a section, like a row of data or a footer, etc, if it is not always visible or always suppressed, then you need to use the Section Expert to enter the formula that will suppress it.

 

Long winded, but hopefully helpful to all.

 

The down-side, is when you change the datasource, it will erase your report, but this can be averted.  Add the stored proc as datasource and then replace each field as needed until the little checkmarks are all gone in the old datasource, then you can safely delete them as datasources.

 

HTH

Yes, stored procs are created and run on the database, so...

 

Crystal does have something about SQL Expressions, but I am not sure how they work, as I use the stored proc and push the data to my report instead of having the report pull the data from the database.

 

Sorry I can't be of more help.