Parameter Passing and Formula Editor ???

[vwduud]

I have a basic report that displays a column of information based on a bank identification number from a Table named RunTable. The RunTable table has two columns, both string columns. First column is named BankID, second column is named Amount.

In the report, I have created a field parameter named "jimbob". In the Formula Editor dialog, I created a Record Selection formula that looks like this:

{Banks.BankID} = {?jimbob}

The RunTable has 9 rows of data:

BankID Amount
001 2003
001 1987
001 254
002 3876
002 5487
002 6598
003 6579
003 8709
003 113

The report will display the input parameter in the a field in the header and the column of data based on the input parameter (Banks.BankID). So, if you run Print Preview and enter '001' for the Discrete Value, '001' prints at the top, and the 3 corresponding Amount values print down the report. Works as expected. For clarification the input field '?jimbob' is linked to a field on the report, just toecho its value (for testing/verification purposes).

Now, for the problem. I am attempting to call this report from a C++ application. I am able to set the input parameter in my C++ code. However, when using the syntax in the formula of the report:

{Banks.BankID} = {?jimbob}

I get an return error from the function PEStartPrintJob. The error is:

"Error in formula <Record_Selection> '{Banks.BankID} = {?jimbob}' This field name is not known"

Of course, with this error, the report does not print.

If I change the formula from the above to a hard coded version like:

{Banks.BankID} = '001'

the report does come up with no errors with the data from the bank with id "001"(obviously). The input field is of course ignored, but is still echoed on the report in its field in the header of the report.

Because I have a field on the report displaying the passed in input parameter, this hard coded method allows me to see that the input parameter is getting passed in and displayed accurately. Changing the input parameter, but leaving the formula hard coded does properly change the field value as it displays on the report.

In summary, I am getting my input value into the report, from my code; its does echo properly on the report when changed. Obviously this is not going to work (hard coded formula) in the real world application). Can anyone offer any suggestions towards a solution to get rid of the error message stated above and make this work?

Thanks - Jim

[springsoft]

Last time I saw these problems was 2000, and memory of solution is fuzzy!

I vaguely recollect that this has something to do with the {} brackets around the parameter name. From your description, it's certainly on the right hand side of the = sign. Or its got something to do with the type of the parameter being passed.

How do you set the parameter in your C++ code:
You have an instance of a report object and then you address a member of the report object's ParameterFields collection, and set it to a value, right?

YOur code shows that the type of the parameter being used by the formula is a string. ('001') Are you sure you are passing a value from your C++ code that Crystal can resolve to a string?

Dave

[vwduud]

How do you set the parameter in your C++ code:
You have an instance of a report object and then you address a member of the report object's ParameterFields collection, and set it to a value, right?

YOur code shows that the type of the parameter being used by the formula is a string. ('001') Are you sure you are passing a value from your C++ code that Crystal can resolve to a string?

Dave

Thanks for your reply Dave. Here is the code for setting the parameters. It is legacy code that has works for years when using MS Access as the database, as opposed to SQL Server.

int CReports::SetParameters(short hJob, const char *args, const char *report)
{
if (!args != NULL) {
return false;
}

PEParameterFieldInfo parameterInfo;
memset(&parameterInfo, 0, sizeof(PEParameterFieldInfo));
parameterInfo.StructSize = PE_SIZEOF_PARAMETER_FIELD_INFO;
parameterInfo.ValueType = PE_PF_STRING;
parameterInfo.CurrentValueSet = TRUE;
strcpy(parameterInfo.ReportName, report);

char *buffer = strdup( args );
if (!buffer) {
return false;
}

char *tok = strtok(buffer, ",");
for (int n=0; tok; n++) {

strcpy(parameterInfo.CurrentValue, tok);

if (!PESetNthParameterField (hJob, n, &parameterInfo)) {
return false;
}
else {
tok = strtok(NULL, ",") ;
}
}

free(buffer);

return true;
}

As you can see, it is setting the parameter type as a PE_PF_STRING, and is setting the value as a char*. My input variable to the report is set up as String value type. As mentioned, the input parameter does make it into the report (can be echoed backed in a field). It just won't recognize the variable name in the comparison. Thanks again for any suggestions - Jim

[vwduud]

I figured it out. Turns out the report did not like "PESetNthParameterField" for setting the field parameter (although strange it worked before for Access for many years). Instead, I used the PEAddParameterCurrentValue API. The following is the modified function. PEAddParameterCurrentValue is down near the bottom.

int CReports::SetParameters(short hJob, const char *args, const char *report)
{
if (!args != NULL) {
return false;
}

PEParameterFieldInfo parameterInfo;
PEValueInfo currentValue;

//get the number of fields in the report
short numfields = PEGetNParameterFields(hJob);

char *buffer = strdup( args );
if (!buffer)
{
return false;
}

//get the first argument from the buffer
char *tok = strtok(buffer, ",");

//loop through the input fields, get their names and assign their values from args
for(int i = 0; i < numfields; i++)
{
//reset the structure - note: PEGetNthParameterField did not like this, and
//returned false when doing memset first JSB 11-30-2004
//memset(&parameterInfo, 0, sizeof(PEParameterFieldInfo));

//get the name of the parameter field: parameterInfo.Name
if(!PEGetNthParameterField (hJob, i, &parameterInfo ))
{
return false;
}
else
{
//set up the rest of the parameter info structure
parameterInfo.StructSize = PE_SIZEOF_PARAMETER_FIELD_INFO;
parameterInfo.ValueType = PE_PF_STRING;
parameterInfo.CurrentValueSet = TRUE;
strcpy(parameterInfo.ReportName, report);

//set up parameter value info structure
currentValue.StructSize = PE_SIZEOF_VALUE_INFO;
currentValue.valueType = PE_PF_STRING;
strcpy(currentValue.viString, tok);

//add the argument value to the report for its corresponding input parameter
if(!PEAddParameterCurrentValue(hJob, parameterInfo.Name, NULL, &currentValue))
{
return false;
}
else//get next argument
{
tok = strtok(NULL, ",") ;
}
}
}
free(buffer);
return true;
}

[springsoft]

Baton Rouge, huh.
My brother was thru there just last month - used a friend's BMW bike to go to Grand Canyon, Nashville, Louisiana, etc then back to Atlanta. Friend got married in a society wedding in Nashville.

Anyway, back to the solved problem - did you change CR version recently? Or get some patches that might have broken existing code??

Anyway, glad to have helped indirectly. Sometimes you just need to talk the problem thru and get some alternative views and then, ka'ching, the lightbulb goes on over your head :-)

Dave
"me and Bobby thumbed a diesel down..."

[vwduud]

Baton Rouge, huh.
My brother was thru there just last month - used a friend's BMW bike to go to Grand Canyon, Nashville, Louisiana, etc then back to Atlanta. Friend got married in a society wedding in Nashville.

Anyway, back to the solved problem - did you change CR version recently? Or get some patches that might have broken existing code??

Anyway, glad to have helped indirectly. Sometimes you just need to talk the problem thru and get some alternative views and then, ka'ching, the lightbulb goes on over your head :-)

Dave
"me and Bobby thumbed a diesel down..."

Well, I haven't been anywhere near Australia... one day though.

As far as the version of CR, I thought about that today as well, as I solved a few other issues. It was not that I upgraded, but had to install the design environment, which is version 8. The reports were all developed in version 7. However, I have had some of the same issues (syntax issues and CR errors prior to the installation). So, I am not sure whether or not that added to the problem.

Thanks again for the insight. I am a firm believer in brainstorming... even if it is from across the pond. Enjoyed it. - Jim

[springsoft]

a pleasure