well this would have to be evaluated during the running of the report...it cannot be done during parameter entry.
You can restrict the entries by using a dropdown list for data entry.
Is this for some kind of security reasons?? There is some security since the user must have a userID / Password to get onto the database....or perhaps it is to restrict users from certain aspects of the report...if so then a second password may be needed....anyway I am just thinking out loud.
Yes there is a formula that can be developed and placed in the report header that could evaluate the input.
the parameter with multi-input {?Users} acts as an array
Now you can reference this inputted array to a table of values in a subreport (the prefered method)...or hard code acceptable values into the report.
then it is just a matter of cycling through the input array to see if all values are acceptable
I'll use the subreport approach
The subreport would simply collect acceptable names into a shared array called "AcceptableNames" from a table
this subreport should go into a subsection of the report header...unsupressed...and made as thin as possible...the sections of the subreport should be supressed though and the subreport/subsection be made as thin as possible.
the next report header section has the formula
@UserCheck
shared stringvar array AcceptableNames;
numbervar i;
stringvar warning := "The following usernames are not acceptable: ";
numbervar badCount:= 0;
for i = 1 to count({?Users}) do
(
if {?Users} not in AcceptableNames then
(
warning := warning + {?Users} + ", ";
badCount := BadCount + 1
);
);
if badCount > 0 then
//get rid of extra ", "
Left(warning,length(warning)-2)
else
"";
THis will display a wraning if there is a problem data or display a null if there is no problem.
In the section expert for Report header B Check the box "Supress Blank Section" and make the formula field "Can Grow"
Hope this helps
Jim Broadbent
JimBroadbent@hotmail.com
