«

Hello, and thank you in advance for any help you can provide.

Each line in our datagrid control contains a product number,
description, and a textbox for the user to enter a quantity-to-order.

Users enter quantities (not necessarily on every line), click the Next
button, and continue. Sometimes users return to a previous page, by
clicking the Previous button, and see quantities that they did not
enter. More often, users return to a previous page to find unwanted
quantities added and wanted quantities deleted.

A dozen customers have reported this problem over the last six months,
but we have been unable to reproduce it in-house. It is extremely
rare, but one week it happened four times.

Has anyone else experienced anything like this? Our solution was
developed by a third party, but I am becoming more familiar with the
source code. I can answer any questions to clarify the issue.


Patterns we have identified
==============================
1. There has never been an equal number of items deleted and inserted.
2. The deleted items are always contiguous to one another. (Items are
organized by a fixed catalog line number.)
3. The inserted items are always contiguous to one another.


Notes
======
1. The solution uses custom paging (datagrid.allowpaging=FALSE).
2. This behavior occurs before any records are written to the SQL
Server backend. (That happens when the user clicks the Save button or
the Place Order button.)
3. Solution was developed in Microsoft Visual Studio .NET 2003.
4. Our in-house Windows PCs are all at Framework level 1.1.4322.2032
(Service Pack 1); the server is also at SP1 level (1.1.4322.2300); am
waiting to hear back from two customers what version of the .NET
Framework they're using.
5. All clients are using Internet Explorer 6.0.

your code does not handle duplicate postbacks. go to you UI, add a unit, hit
you update button. then refersh the page after the update (should get a
repost message from browser). you will see the problem.

common fixes.

1) store a transaction id with evey postback to detect its been done
2) for carts, have user select quanity rather then add/delete.

you need to do #1 for cc charging our you will double bill.

-- bruce (sqlwork.com)


"kingflux" <> wrote in message
news: ups.com...
> Hello, and thank you in advance for any help you can provide.
>
> Each line in our datagrid control contains a product number,
> description, and a textbox for the user to enter a quantity-to-order.
>
> Users enter quantities (not necessarily on every line), click the Next
> button, and continue. Sometimes users return to a previous page, by
> clicking the Previous button, and see quantities that they did not
> enter. More often, users return to a previous page to find unwanted
> quantities added and wanted quantities deleted.
>
> A dozen customers have reported this problem over the last six months,
> but we have been unable to reproduce it in-house. It is extremely
> rare, but one week it happened four times.
>
> Has anyone else experienced anything like this? Our solution was
> developed by a third party, but I am becoming more familiar with the
> source code. I can answer any questions to clarify the issue.
>
>
> Patterns we have identified
> ==============================
> 1. There has never been an equal number of items deleted and inserted.
> 2. The deleted items are always contiguous to one another. (Items are
> organized by a fixed catalog line number.)
> 3. The inserted items are always contiguous to one another.
>
>
> Notes
> ======
> 1. The solution uses custom paging (datagrid.allowpaging=FALSE).
> 2. This behavior occurs before any records are written to the SQL
> Server backend. (That happens when the user clicks the Save button or
> the Place Order button.)
> 3. Solution was developed in Microsoft Visual Studio .NET 2003.
> 4. Our in-house Windows PCs are all at Framework level 1.1.4322.2032
> (Service Pack 1); the server is also at SP1 level (1.1.4322.2300); am
> waiting to hear back from two customers what version of the .NET
> Framework they're using.
> 5. All clients are using Internet Explorer 6.0.
>

Thank you for writing, Bruce. Duplicate postback is a real
possibility, though if it is, I don't think the users are doing it
intentionally.

Example: When I refreshed the page, as you suggested, a dialog box
appeared: "The page cannot be refreshed without resending the
information." Clicking Retry does "delete" the items; clicking Cancel
causes "Warning: Page has expired." No users have reported such
behavior at any time.

HOWEVER, some users who have reported this rare deletion/insertion have
reported that the grid appeared to jump two pages when they click the
Next button once. Could this be the same thing? I have tried to get
the grid to skip a page with all manner of double-clicking and other
antics, but have never made it happen.

Is it possible that something is happening internally on the grid or
the page that might cause or mimc this rare duplicate postback
behavior? (Almost like a mouse click that Windows interprets as a
delayed double click; I have seen this many times.)


Regarding your suggestions, forgive me: being primarily a sysadmin who
occasionally dabbles in scripting and MS Access VBA, I am not familiar
with the implementation of a transaction id for something at this
level.

- Is there a "transaction id" within the postback process that I can
utilize?
- If not, how would you generate it?
- How would I determine if the postback was successful?

(We are using all custom code; no carts are being used as far as I can
tell.)


Meanwhile, I'm tediously plowing through a couple of articles that I
found when I googled for 'duplicate postback' and trying to figure out
if our current code *is* trying to prevent that:

Preventing Duplicate Record Insertion or Page Refresh on postback of a
Web Form
http://aspalliance.com/687

Preventing Duplicate Record Insertion on Page Refresh
http://www.codeproject.com/aspnet/formKeyManager.asp


-Tim

I am thrilled to announce that we figured out what is happening with
the 'unwanted data injected into datagrid textbox' (posted Nov 13 2006)
and it is now fixed on our site.

I found the cause purely by accident, when testing on an older server
that is significantly slower than our production web server. I found
that I could click the Next button multiple times while I waited 5-8
seconds between page loads. Whenever I did, it "jumped" the same
number of pages and copied the values from the first page to all the
subsequent pages that were "touched" in the transaction. Nothing on
the screen would ever suggest to the user that such a thing had
occurred.

Mr. Barker from sqlwork.com was definitely on the right track when he
suggested duplicate postback was the likely problem -- so THANK YOU,
sir, very much!

At the bottom of the page, just before the closing HTML tag, we added
this javascript code, which disables all buttons on the page and
displays a "Processing..." message until the next page loads:


<script language="javascript">
/* Code to fix multi-click issue */

// handle the unload of the form
window.attachEvent("onbeforeunload", disableWindowControlsOnUnload);

// loop through relevant input controls and make sure the users do
attempt a postback
var elementCollection = document.getElementsByTagName("input");
if ( elementCollection != null )
{
for ( var i = 0; i < elementCollection.length; i++ )
{
var element = elementCollection(i);
if ( element.type == "submit" || element.type == "button" )
{
element.attachEvent("onclick", disableWindowControlsOnClick);
element.attachEvent("ondblclick", handleDoubleClick);
}
}
}

// this method used to disable any input controls from firing
function disableWindowControlsOnUnload()
{
document.body.style.cursor = "wait";
for ( var j = 0; j < document.forms.length; j++ )
{
var elementCollection =
document.forms(j).getElementsByTagName("input");
for ( var i = 0; i < elementCollection.length; i++ )
{
var element = elementCollection(i);
if ( thisElement.type == "submit" || thisElement.type == "button" )
element.disabled = true;
}
}

return true;
}

// this will make sure no events create a double post scenario
var bubbleEvent = true;
function disableWindowControlsOnClick()
{
if ( bubbleEvent == true )
{
document.body.style.cursor = "wait";
showProcessingBanner();
bubbleEvent = false;
}
else
{
window.event.cancelBubble = false;
window.event.returnValue = false;
}
}

function handleDoubleClick()
{
window.event.cancelBubble = false;
window.event.returnValue = false;
}


function showProcessingBanner()
{
var bannerElement = "<div style='position:absolute; z-index:99;
border-style:solid; background-color:white; width:400px;
height:200px;'></div>";
var banner = document.createElement(bannerElement);

banner.innerHTML = "<span style='color:black; font-size:large;
vertical-align:middle;'><center><br><br><br>Processing...</center></span>";
banner.style.left = ( window.screen.availWidth / 2 ) - 200;
banner.style.top = ( window.screen.availHeight / 2 ) - 100;
document.body.insertBefore(banner);
}

</script>


kingflux wrote:
> Thank you for writing, Bruce. Duplicate postback is a real
> possibility, though if it is, I don't think the users are doing it
> intentionally.
>
> Example: When I refreshed the page, as you suggested, a dialog box
> appeared: "The page cannot be refreshed without resending the
> information." Clicking Retry does "delete" the items; clicking Cancel
> causes "Warning: Page has expired." No users have reported such
> behavior at any time.
>
> HOWEVER, some users who have reported this rare deletion/insertion have
> reported that the grid appeared to jump two pages when they click the
> Next button once. Could this be the same thing? I have tried to get
> the grid to skip a page with all manner of double-clicking and other
> antics, but have never made it happen.
>
> Is it possible that something is happening internally on the grid or
> the page that might cause or mimc this rare duplicate postback
> behavior? (Almost like a mouse click that Windows interprets as a
> delayed double click; I have seen this many times.)
>
>
> Regarding your suggestions, forgive me: being primarily a sysadmin who
> occasionally dabbles in scripting and MS Access VBA, I am not familiar
> with the implementation of a transaction id for something at this
> level.
>
> - Is there a "transaction id" within the postback process that I can
> utilize?
> - If not, how would you generate it?
> - How would I determine if the postback was successful?
>
> (We are using all custom code; no carts are being used as far as I can
> tell.)
>
>
> Meanwhile, I'm tediously plowing through a couple of articles that I
> found when I googled for 'duplicate postback' and trying to figure out
> if our current code *is* trying to prevent that:
>
> Preventing Duplicate Record Insertion or Page Refresh on postback of a
> Web Form
> http://aspalliance.com/687
>
> Preventing Duplicate Record Insertion on Page Refresh
> http://www.codeproject.com/aspnet/formKeyManager.asp
>
>
> -Tim