Problems with date parameters 1

[jwaldner]

I have a problem with a report where when I hit F5 to update parameters I get prompted twice once for the end and start dates [in that order] then again for the rest of the parameters. Not only is it annoying to be prompted twice. but the order makes it easy to enter the dates in the wrong order. On the second prompt screen the dates are there and in the right order with the right dates, start date then end date. This all started when I made the rest of my parameters dynamic. Not sure what that has to with the price of rice. Has any one seen weirdness like this before?

 

[briangriffin]

Does this report have a subreport? That is the usual culprit when prompts appear twice.

 

[jwaldner]

no, but it does have a command with date parameters. Its acting like it thinks there are two sets of dates. The command has a start and end date that is tied in to start and end date parameters in the report.

 

[jwaldner]

I figured this out. I was using the command with the date range to select parameters so it was prompting me for those. Then it displayed the rest of the parameters based on the first results. To resolve this I added the same select in a command without a WHERE clause, then I only get prompted one time. The only downside is that its slow because there is no filter on the data for the parameters. I wish there was a better way to do this.

 

[briangriffin]

I know what you mean now - since you have a mixture of dynamic and static parameters in the report and the command you get two parameter dialogs, but you're not getting prompted for the same parameter twice (the value from the first dialog is retained in the second dialog).

I don't think you'll be able to make it work as designed. Depending on the size of the recordset being returned by the command, and if you're willing to take the performance hit, you could take the parameters out of the command and create them within the report. This is pretty inefficient, but might be acceptable.

If that's not an option let me know - you might be able to get something workable with a stored procedure, but I'd have to do some testing.