October 24, 2007 at 7:43 am
When some parameters are selected from drop-down boxes, the screen refreshes. With users on remote links, this can cause a delay of a minute or so in between choosing parameters which is unacceptable. Does anyone know how to control this?
BTW, I discovered that with date parameters and string parameters with calculated defaults, putting these first in the parameter list avoids a lot of unnecessary screen refreshes. However, where one parameter depends on another, there doesn't seem to be any alternative.
December 31, 2007 at 5:00 am
hi,
If one parameter (sub category) appears after selection of other parameter (category) then it is necessary that screen should refresh. At that time it will run your query from dataset and according to your selection it will select other data. So, if you have one parameter output depends on other then it is not possible that u can stop refresh.
Hope this helps.
Vijay
January 2, 2008 at 2:58 am
Yes, there doesn't seem to be a way round it for 'cascading parameters'. However you can stop the screen refresh for date parameters, by setting the default value to another parameter
January 3, 2008 at 5:02 pm
Have you thought of storing the parameter values in a parameter table? This will decrease your query/refresh time. Even with parameters that rely on other parameters.
All of my parameters are refreshed with new values from the database nightly and are pulled from a parameter table with the basic values of ParameterName, ParameterLabel, ParameterValue. This has really increased the performance and refresh time on reports.
Sabrina
January 4, 2008 at 2:53 am
That sounds interesting, Sabrina. How would that work say if I wanted to report on projects across the world and would be choosing continent, country and project from 3 different lists? Also, is your parameter table held locally or on the server?
January 4, 2008 at 8:35 am
I have all the parameters go into a table. Example:
ParameterName ParameterLabel ParameterValue
Country Country UnitedStates
Country Country Australia
Continent Continent North America
Continent Continent Asia
Project Project SQL
Project Project Java
Manager Manager Sabrina
Manager Manager Cory
The table is on the server and the report calls the parameters through a data query (one for each parameter) to this table. The table itself is populated by a select 'Country' as parametername, 'Country' as parameterlabel, columnname as ParameterValue from table where columnname <> '' or columnname is NOT NULL order by columnname.
ParameterLabel is good to use if your SQL name for the parameter is 'computerafied'...ie not user friendly.
January 4, 2008 at 10:27 am
Hmmm... how does this work if the user selects a continent and then expects to get a choice (in the country parameter drop-down) of only those countries in that continent? And once they've selected a country they should get a list only of those projects assigned to that country?
January 13, 2008 at 4:03 pm
Sorry, busy week.
Add two more columns MasterParameter and MasterParametervalue, Master Parameter would only be filled for those columns that have a master or linked parameter that determines their value.
ParameterName ParameterLabel ParameterValue MasterParameter MasterParameterValue
Country Country UnitedStates Continent North America
Country Country Great Britain Continent Europe
Country Country France Continent Europe
Then have the query look for all Country parameters where the MasterParameterValue is Europe, what ever continent ONLY.
Same idea for the project. The populatino of the parameters would be a SQL statement based on your buisness rules for the Parameter selection.
January 14, 2008 at 3:41 am
You said in an earlier post: 'All of my parameters are refreshed with new values from the database nightly'. So where is your parameter list stored if not on the database itself?
Thanks.
January 20, 2008 at 10:52 am
My parameters are stored on the database. They pull from stored procedures in the report that call the parameter table I described to you. I have a stored procedure that nightly complies all the parameter information into the parameter table. This way, the report is NOT asking for information from the database tables that contain ALL the information, nor is the report calling on a datamart. Just the information in the parameter table that has been pared down to ParameterName, ParameterLabel, ParameterValue, MasterParameterName, and MasterParameterValue.
The nightly stored procedure that pulls the information takes about 10 minutes to run or more depending on the UNIONs and other information being feed to the parameter table. It is a LONG stored procedure...but having my reporting set up this way has drastically reduced the delay times.
January 20, 2008 at 1:52 pm
Depending on how many transactions occur in your database some smart use of indices on the columns used to populate parameter values could also help.
January 21, 2008 at 3:31 am
I don't think the way our lists of parameter values are stored is really the problem for us - where they are stored is more the issue. It's the trip back to the database to get the list, whether short or long, which causes the delay and that's because of the slow connections. If the report could make only one trip to pick up all that info, it would help.
OOI, Sabrina, do you schedule your stored proc to run in SQL Server or schedule a subscription for the report itself in Report Manager?
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply