Anyone have a clue why this happens??

[Dan]

Hi guys

I have an aspx page that accepts a posted to field, the id number of a
product.

On the page it then loads the details and allows editing of the product with
a save button. The save button fires off sql to save the changes using that
id number posted.

My problem i had was that between postbacks the id number was not retained.
So when i clicked save and a round trip post back occurred the id was lost.
So i made my variable that accepted the product id static. Problem solved.

However i have now found that if i load the page and edit a product and my
collegue loads the page on his comp to edit a different product that when he
clicks save it attempts to update the details on his page to the product id
of the one i am looking at.

So somehow my posted data has stayed and when he has gone in to his it has
kept my product id? Anyone have a clue how that can happen?

Here is a snippet of my page load function (c# code)

if(!Page.IsPostBack)

{

vestry.dbCommands dbObj = new vestry.dbCommands();

System.Collections.Specialized.NameValueCollection postData = new
System.Collections.Specialized.NameValueCollection();


if(Request.RequestType == "GET")

postData = Request.QueryString;

else

postData = Request.Form;

productId = int.Parse(postData.Get("productId"));

...............}

As you can see from above i take the posted data and set it to my static int
productId variable. I am presuming it is because i set it static that this
occurs. But how, without setting the product id static, can i keep it
retained from page to page without it being placed inside a text box or
similar?

Thanks

 

[Peter Rilling]

Well, you never really want to make something state in a web environment
because all users will end up sharing the same copy of the variable.

Create a hidden field and set the value of that field to you ID when the
page renders. Then grab that ID when the page is submitted.

 

[Jay R. Wren]

Hi guys

I have an aspx page that accepts a posted to field, the id number of a
product.

On the page it then loads the details and allows editing of the product with
a save button. The save button fires off sql to save the changes using that
id number posted.

My problem i had was that between postbacks the id number was not retained.
So when i clicked save and a round trip post back occurred the id was lost.
So i made my variable that accepted the product id static. Problem solved.

However i have now found that if i load the page and edit a product and my
collegue loads the page on his comp to edit a different product that when he
clicks save it attempts to update the details on his page to the product id
of the one i am looking at.

So somehow my posted data has stayed and when he has gone in to his it has
kept my product id? Anyone have a clue how that can happen?

Here is a snippet of my page load function (c# code)

if(!Page.IsPostBack)

{

vestry.dbCommands dbObj = new vestry.dbCommands();

System.Collections.Specialized.NameValueCollection postData = new
System.Collections.Specialized.NameValueCollection();


if(Request.RequestType == "GET")

postData = Request.QueryString;

else

postData = Request.Form;

productId = int.Parse(postData.Get("productId"));

..............}

As you can see from above i take the posted data and set it to my static int
productId variable. I am presuming it is because i set it static that this
occurs. But how, without setting the product id static, can i keep it
retained from page to page without it being placed inside a text box or
similar?

Thanks

I suggest much reading on how ASP.NET really works. Google for ASP.NET
Page Lifecycle.

While not a static variable, you can maintain state information in the
Session or Application dictionaries.

 

[Daniel]

Thanks guys

Thanks Jay but thats not what i am after. Spot on tho Pete, i presumed with
the code behind on the aspx pages that for each user a new instance of the
code behind class would be created, therefore keeping the static var to just
that user. From what you have said this isn't the case at all, i was hoping
that aspx had destroyed the need for the old style 'hidden fields' posting.

D