Nasty DataSourceCotnrol Behavior

  • Thread starter Thread starter Mark Olbert
  • Start date Start date
M

Mark Olbert

I just spent several frustrating hours tracking down a subtle problem involving a simple web page. I'm sharing the solution so as to
spare others a similar experience.

The web page has only three controls, all of which are bound to SqlDataSource controls: two dropdowns and a repeater. However, the
contents of the second dropdown depend upon the selection made in the first dropdown, and the contents of the repeater depend upon
the selections made in both dropdowns.

The problem is this: SqlDataSource controls have a connection string property. If you use a different datasource for development
than you do on the production site, you have to change the connection string at some point in the page lifecycle when it runs in the
production environment or the data may not be retrieved.

This is not an unusual situation, and with the old data adapter/dataset load model I handled it by assigning connection strings in
the Page_Load method.

Unfortunately, SqlDataSource controls don't persist their connection strings..so if you're going to change them you need to do so on
every postback. You may be able to do this in the Page_Load method, but to be safe I opt to do it by overriding the OnInitComplete
method (because I believe event processing takes place immediately after OnInitComplete, and the controls must be properly
configured before event handling takes place).

Personally, I think the lack of persistence of connection strings is a nasty little bug that ought to be squashed by Microsoft ASAP.
Sometimes I get the feeling that Microsoft doesn't test ASP.NET in the typical "development environment is different from production
environment scenario". I say this because there are too many little "bolt on" solutions to the "problems" caused by multiple
environments (e.g., having to rewrite the Web.config file). It would be nice if they did.

- Mark
 
Hi Mark,

At some respect i dissagree because connection string is used only when
getting the data from data source. Having data populated, there is no need to
retrieve it again on every postback since viewstate was designed to store all
the details control needs to rebuild itself without acquiring data again and
again. I understand this case is different as combo boxes depend on each
other, but in most scenarios connection string is fixed and set for
IsPostBack == false.

Best regards
 
Milosz,

Unfortunately, the problem occurs not because of the interaction between controls, but because the ASPNET engine tries to use the
SqlDataSource control as it was configured during development. In other words, this code will fail, even if there is no control
binding to the data source control:

protected void Page_Load( object sender, EventArgs e )
{
if( IsPostBack )
{
}
else
{
// dsrcMatch's connection string was set to something appropriate to the development environment

dsrcMatch.ConnectionString = CorrectConnectionStringForEnvironment
}
}

I found this out when various pages that use the SqlDataSource control blew up on me when I deployed them.

A solution, as I mentioned in the earlier post, is to do this:

protected override void OnInitComplete( EventArgs e )
{
base.OnInitComplete(e);

dsrcMatch.ConnectionString = CorrectConnectionStringForEnvironment
}

This doesn't blow up, because before the data source control gets "activated" in the course of the page load its connection string
is set to the correct value.

You're right about the ViewState holding state information...but every databound page I've ever written needs to access some data
source in the course of its processing in order to put the information into the ViewState (by way of setting control properties,
usually).

Oftentimes that happens after various postbacks, not just on the first postback. For example, consider a page using a Wizard or a
MultiView, each step of which contains databound controls. Not only wouldn't I want to have to databind the controls on the
"invisible" steps, but many times I can't, because I won't know what to fill them with until after the user walks through the first
couple of steps and postbacks.

So I stand by my assertion that it would be much more convenient for the SqlDataSource control to store its connection string in
ViewState or ControlState. Of course, that introduces a security risk, but I bet that could be handled by encrypting the
information.

- Mark
 
Hi Mark,

Thank you for sharing your experience with the community and your feedback
regarding the DataSource control's ConnectionString property.

Besides your solution to set the ConnectionString in OnInitComplete, you
could also do it in the DataSource control's Init event.

Regards,
Walter Wang ([email protected], remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Good morning Mark,

I understand your reasoning, but to be honest i don't find as a problem
because i never use sql data source on my pages as I tend to move all
database access code to separate place. In addtion to what you mentioned -
security is also one of the reasons, plus keeping viewstate as tight as
possible. It's also simple to use <%$ ConnectionString %> (i know that not
the case now) Anyway, as i signalised in last reply, I disagree only at some
point.

Best regards
 
I think I know what you mean about not using sql data source controls too much. Frankly, I find there's too much stuff that takes
place "behind the scenes" for my taste. I prefer to not have databinding take place until I explicitly want it to...but then again,
maybe I'm just stuck in an ASPNET 1.1 rut :).

- Mark
 
Back
Top