PostBack while selecting a parameter

Hi,

I'm working on a report having 2 date parameters(which uses calendar control) and a dropdownlist. But on selecting each of these parameters, the page refreshes. For eg On selecting a date from the calendar control results in a postback. The same is the case with the dropdownlist. Could you please help to resolve this issue? We need the postback to happen only on clicking the 'View Report' button.

Also, is there any way to customize the 'View Report' button. It always appears in the right hand side. Can we set the position of this button so that it appears just below the paging button?

Thanks in advance,

Sonu.

1. No, it's not possible to avoid postbacks when you enter parameters one by one.

2. There is no way to customize the position of the button but you can change the style of the button in your report manager by using the ReportingServices.css file in the following folder (probably):

C:\Program Files\Microsoft SQL Server\MSSQL.4\Reporting Services\ReportManager\Styles

Please refer to more details in the following link:

http://msdn2.microsoft.com/en-us/library/ms345247.aspx

Shyam

sql

Postback takes a LONG time!

I have one other issue, possibly related to my last post, that I thought I
should post in a separate question.
When I specify a default value for a parameter using an expression, the form
postback process seems to get scrambled. If I enter a value in a text
parameter, then click "View Report", the form will do a postback, but NOT run
the query. If I click View Report again, the report runs fine.
This delayed postback occurs on any text field parameter, and can be
observed by entering text in a parameter field, then clicking in another
parameter field. This effect is very disconcerting.
As in my other question, I'm thinking this is a RS bug, but is there a
workaround?
Thanks in advance,
MikeThe server can not determine the dependencies between parameters when some
of them are expressions, so it is conservative and assumes that a dependency
exists. When you navigate away from the text box (to another text box or to
the view report button), the page posts back to get new defaults and valid
values for downstream parameters. If there is no dependency, you can
reorder the parameters to prevent the post back. A parmeter can only depend
on parameters that came before it. So if you make your expression based
parameter the last one, there will be no auto post back.
--
This posting is provided "AS IS" with no warranties, and confers no rights
"rdcpro" <rdcpro@.discussions.microsoft.com> wrote in message
news:691D2719-81E7-46B8-9F26-E3515DD8CDB2@.microsoft.com...
> I have one other issue, possibly related to my last post, that I thought I
> should post in a separate question.
> When I specify a default value for a parameter using an expression, the
form
> postback process seems to get scrambled. If I enter a value in a text
> parameter, then click "View Report", the form will do a postback, but NOT
run
> the query. If I click View Report again, the report runs fine.
> This delayed postback occurs on any text field parameter, and can be
> observed by entering text in a parameter field, then clicking in another
> parameter field. This effect is very disconcerting.
> As in my other question, I'm thinking this is a RS bug, but is there a
> workaround?
> Thanks in advance,
> Mike|||Thanks Brian,
This particular control is the last parameter, but there is also a select
box that is the second-to-last parameter. This one uses a default value, but
not an expression. In particular, it has a set of values that look like
Label Value
foo 0
bar 1
snafu 2
and the default value is specified as:
0
and not
=0
In this case, a postback shouldn't occur, because this is not an expression
but a scalar value, right?
And even if it were an expression, while the server doesn't know if there is
a dependancy, the Designer (me) knows. It seems to me that when I design a
report with parameters that use expressions, I should have a checkbox to
disable postback or declaratively state there is no dependancy.
Any thoughts?
Thanks again,
Mike
"Brian Hartman [MSFT]" wrote:
> The server can not determine the dependencies between parameters when some
> of them are expressions, so it is conservative and assumes that a dependency
> exists. When you navigate away from the text box (to another text box or to
> the view report button), the page posts back to get new defaults and valid
> values for downstream parameters. If there is no dependency, you can
> reorder the parameters to prevent the post back. A parmeter can only depend
> on parameters that came before it. So if you make your expression based
> parameter the last one, there will be no auto post back.
>|||In case others run into this issue, I wanted to post my resolution.
At issue is the fact that a report parameter with an expression is assumed
to be dependant on another report parameter, even when in fact it's only
dependant on a global value or even if it simply uses an expression to return
a scalar result. So, when you set a default value using an expression, the
control is "disabled" and there is no way for the user to physically set the
control without first entering a fake value in another field, then causing a
postback to "refresh" the parameter. Only then can the user set the value
for the parameter using an expression. Of course, before the user runs the
query he/she must remove the "fake" value.
In my case, a user might enter a date in my "End Date" field, then click
"View Report". Instead of actually seeing the report, the screen blanks, a
postback occurs, and it appears to the user that either nothing happened, or
the report returned no results. They have to click "View Report" again to
get the report to run.
Evidently, the behavior is "by design" inasmuch as RS isn't smart enough to
realize there is no dependancy for this parameter, and there is no way in the
report designer to declaratively state as much.
In my case, I simply wanted to set the default value of the parameter to
"true" in one folder, and "false" in another. My solution was to use the
same approach that creating a linked report would use. Upload the report
with no default value on the control, then in the Report Manager, manually
specify the default value I want (either true or false) in the Properties >
Parameters page.
It would be really nice if there was a similar option in the Report
Designer, or if you could set the default to a scalar value directly the same
way you can for a drop-down parameter!
Hope this helps someone,
Mike
"rdcpro" wrote:
> Thanks Brian,
> This particular control is the last parameter, but there is also a select
> box that is the second-to-last parameter. This one uses a default value, but
> not an expression. In particular, it has a set of values that look like
> Label Value
> foo 0
> bar 1
> snafu 2
> and the default value is specified as:
> 0
> and not
> =0
> In this case, a postback shouldn't occur, because this is not an expression
> but a scalar value, right?
> And even if it were an expression, while the server doesn't know if there is
> a dependancy, the Designer (me) knows. It seems to me that when I design a
> report with parameters that use expressions, I should have a checkbox to
> disable postback or declaratively state there is no dependancy.
> Any thoughts?
> Thanks again,
> Mike
> "Brian Hartman [MSFT]" wrote:
> > The server can not determine the dependencies between parameters when some
> > of them are expressions, so it is conservative and assumes that a dependency
> > exists. When you navigate away from the text box (to another text box or to
> > the view report button), the page posts back to get new defaults and valid
> > values for downstream parameters. If there is no dependency, you can
> > reorder the parameters to prevent the post back. A parmeter can only depend
> > on parameters that came before it. So if you make your expression based
> > parameter the last one, there will be no auto post back.
> >
>

Postback causing Database Transactions to Replay

Hey,

I hope someone can quickly tell me what I am obviously missing for this weird problem.

To give a general picture, I have an ASP.net webpage that allows users to select values from several dropdown menus and click an add button which formats and concatenates the items together into a listbox. After the listbox has been populated the users have the option to save the items via a save button.

The save button parses each item in the listbox to basically de-code the concantenated values and subsequently inserts them into a table residing on a backend MSSQL 2005 database.

PROBLEM:

In the process of testing the application, I noted this strange behavior. If I use the webpage to insert the values, go to the table where the values are stored and delete the rows; Upon a refresh of the web page the same actions seem to be getting replayed and the items are again inserted into the table.

Naturally, what I'd really like would be for the page to refresh and show that the items aren't any longer there and not the other way around.

If the code that performed the insert was residing in a component that was set for postback I'd expect this type of behavior but its in the Save buttons on_click event. I have tried practically everything in effort of targeting the problem but not having much luck with it.

Is this behavior practical and expected in ASP.net or has anyone ever heard of anything similar? I have never encountered this type of problem before and was hoping someone could provide some clues for resolving it. If more information is required I'd be happy to supply it. Hopefully, there's a simple explanation that I am simply unaware since I haven't experienced anything like this before.

Anybody got any ideas?

Thanks.

Do you know about the page method IsPostback?

that is,

in page_load (or whatever)

if (!Page.IsPostBack)
{

}

|||

Hi Peter,

Yes, I am familiar with the IsPostBack method and I realize that any code placed inside of the if (!Page.IsPostBack) {} will typically only be executed upon the initial load of the page if that's where the condition is placed. I explored the possibility of overlooking that somewhere in my code and also experimented by placing that condition a various points in the code starting with the obvious, "the save_onClick event" but results are either the data doesn't get inserted into the database or it will insert the data and persist manipulation of the data in the database.

As I presently have it setup, on the btnSave_OnClick event; the data is inserted into the database table by looping through all the values in one listbox, then that listbox is cleared of all items and another listbox is populated with the inserted data variables through an active connection to the database and a select all statement. The intent was to allow the users to see the data they just inserted into the table. I suppose I could remove this feature and resolve the problem but I'd much rather identify why its happening and come up with a more viable solution.

I am open to any alternative solutions as well if the outcome will produce the desired results.

Any other thoughts?

|||I'm having trouble following where the problem might be but I'm sure it's solvable. could be a databind problem? an event order problem? maybe want to think about using page_prerender event. Sorry can't be much more help. don't give up!|||

Thanks for trying Peter.

I have managed to target the specific problem now. Debugging the app shows me the issue is that (refreshing or reloading) the page, is causing the on_click event of the save button to be fired. So it appears I was right on target with the description of the problem as the inserts are actually being replayed to the database upon a refresh of the page.

So what I need to determine is what can be done to prevent previous events of the button from being retriggered on a refresh but allowed on a normal postback (if there is any such animal).

Obviously implementing the !Page.IsPostback method in the block of code for the button_click event won't work because the records would never get inserted and I can't place the button_click event inside of the page_prerender event either.

There has got to be a simple method of preventing this from happening. Maybe some way to programmatically distinguish a page postback from a page reload would be an option?

Anyway, I'll keep posting in other forums to see if I can get some additional feedback. I simply can't believe that this type of thing is only new to me.

Thanks again.

|||can you post a simple example that demonstrates your problem?|||

Sure.

I am using a Standard Button, a Listbox, and C# with ASP.net. So far I have examined other methods that may give me what I need in terms of behavior including enableViewState and a few others but I can't seem to control the _Click event from replaying the previous action upon reload of the page.

 
1//Save button iterates through the listbox and acquires the data added by the user2protected void btnSave_Click(object sender, EventArgs e)3 {4 String adUserInsert ="";56try7 {8for (x = 0; x < lstUser.Items.Count; x++)9 {10 adUserInsert = lstUser.Items[x].Text.ToString();11 insertRecords(adUserInsert);12 lstInsertedUser.Items.Add(adUserInsert);13 }14 }15catch16 {17//Error Trap18 }19 }2021//This function inserts the record into the database22private void insertRecords(String adUserInsert)23 {2425try26 {27 String sqlConnString ="Provider=SQLNCLI;Server=TESTSERV;Database=Users_db;Uid=sa;Pwd=p@.sswrd25;";28 String sqlQuery ="INSERT INTO Users_db VALUES('" + adUserInsert +"')";29 OleDbConnection sqlConn =new OleDbConnection(sqlConnString);30 OleDbCommand sqlCommand =new OleDbCommand(sqlQuery, sqlConn);31 sqlConn.Open();32 sqlCommand.ExecuteNonQuery();33//Close the DB connection after use34 sqlConn.Close();35 }36catch37 {38//Error Trap39 }40 }