views:

489

answers:

3

I have an app where I need to dynamically choose an SQLDataSource for a GridView so I can use 1 of 2 stored procedures, depending on who is logged into the system.

My problem is that I am using logic like this, in the button click...

If Session("SiteType") = "Type1" Then
     GridView1.DataSourceID = "SqlDataSource2"
Else
     GridView1.DataSourceID = "SqlDataSource1"
End If
GridView1.DataBind()

This happens when you click the button that reveals the panel with the gridview in it.

The user then makes changes (basically adjusting a text box on one or more liens of the grid) and then clicks "save". However, the gridview no longer knows its DataSourceID once this happens, so when I try to go through the gridview's rows - there are none.

If, in the save button's click, I put the same code, it (of course) blanks out any of the data changes I made in the form.

So, simply put - how do I dynamically choose the SqlDataSource, but only one time, so that the program then keeps that SqlDataSourceID associated with the gridview until the end of the cycle? Is this a ViewState thing? I don't totally understand ViewState...

Pardon my ignorance - I'm assuming this is kind of simple, but I just don't have a ton of .NET experience. If there is a better way, I'd be interested in hearing that as well - that said, time is of the essence so I'm kind of looking for the quick fix right now (boss is breathing down my neck.. heh).

Thanks!

A: 

I've done this by simply putting the option into a cookie and when I need it again pulling that option down from the cookie.

Cookies, Session and ViewState all generally work the same. They are a simple way of persisting information for a limited amount of time. You create a key, you add a value and then save the key back to what ever medium you are going to use be it a cookie, session or viewstate. When you need the value again, you just find the key in from the perstent medium, load the key/value pair and then access the value by ususally putting it back into a variable of sometype.

Good luck, and hope this helps some.

Chris
A: 

You need to rebind the grid on each postback because you are setting the datasource at runtime in code.

Add this to the pages load event handler:

If Page.IsPostback Then
    If Session("SiteType") = "Type1" Then
       GridView1.DataSourceID = "SqlDataSource2"
    Else
       GridView1.DataSourceID = "SqlDataSource1"
    End If
    GridView1.DataBind()
End If
geoff
This is esstentially what I am doing, but it's not in the Page_Load, but on 2 separate button clicks - one for the initial load, and one to save the changes. However, the second time I do it, on save, it's reloading from the database, and clearing out the changes I made on the rows, which is the root problem... I need a way to set it, dynamically, but then not re-bind until after the save action takes place.
Bryan
(side note: I did try it in the Page_Load, but it fails because certain data the SqlDataSource requires for the stored procedure aren't yet determined until a few steps are completed - so it has to be on a button, not on the page_load)
Bryan
Actually you probably need to bind earlier in the Page Init event. Thats because Asp.net loads the viewstate after the Init event but before Load. So you need to have your grid databound before viewstate is loaded in order to 'maintain' any changes.
geoff
Your sqldatasource data could be saved in Session State or a Cookie in order to be available in the Init event.
geoff
A: 

I would just go and and save it as a session variable. Ex. Session("datasource") = myDataSource

Then you set your GridView's datasource as such: MyGridView.datasource = session("datasource") MyGridView.bind()

That should do it.

Hope this helps' David.

David
I would really not use the session for stuff like that. At the most, you could store the DataSourceID in it but certainly not complex (and stateful) objects like a data source. There have been many discussion about what and what not to store in the session but I recommend a minimalistic use of the session, only using it when there is no better alternative. I've seen a lot of occasions where usage of the session had code/design smells around it, like using it to store complete data sets to transport data between pages.
Sandor Drieënhuizen