Re: Nasty DataSourceCotnrol Behavior

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

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
--
Milosz


"Mark Olbert" wrote:

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



On Wed, 28 Feb 2007 16:23:18 -0800, Milosz Skalecki [MCAD] <mily242@xxxxxxxxxxxxxxxxx> wrote:

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

.

Relevant Pages

  • Re: Simple Threading Problem with WinForm
    ... // The delegate to call the method to set the data source. ... including your update of the status bar. ... Also, if you bind to dsLocal.Tables, the data grid will automatically ... > StatusBar control. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Adding records via datagrid
    ... Data binding as a paradigm nicely ... abstraction for generic unbound code involve control naming conventions, ... Again, limitations of the data source object -- if you write your own, ... custom data control to see if I can figure out what you mean. ...
    (microsoft.public.vb.controls)
  • Re: Explicitly create data object bound to control
    ... is the data which data source supplies to ObjectDataControl. ... Selecting this first item has no ... control. ... you're dealing with business objects, they are supposed to be created ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Explicitly create data object bound to control
    ... is the data which data source supplies to ObjectDataControl. ... control. ... What they mean is that, say, you have a list of customers, and you ... you're dealing with business objects, they are supposed to be created ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: DataGrid DataSource is null on postback
    ... That is perfectly normal since data source of a control is not stored over ... postback since control already saves its state with ViewState (and also ... > protected void DataGrid1_PageIndexChanged(object source, ...
    (microsoft.public.dotnet.framework.aspnet)