Please Help ASAP!

[heinscott]

We just started getting a new problem this last weekend, and for the life of me, I can't figure out why!
It seems that certain customers, after putting in an address for shipping, and clicking the button to continue, find that the state (province) and zip code have been changed to reflect that of our default warehouse. It looks like the problem will go away after cookies are cleared out, but, please... why would this problem just start occuring? This is a big deal, as we've had about 8 customers in the last 3 days call to complain of this. God forbid we actually recieve some orders that will end up being sent to the wrong state! And if this helps, the city is not being changed at all. Just the state and zip code.
Thank you to anyone who can help us out with this situation!

Scott
PoolGeek.com

[jmestep]

I'm sure you've already checked to make sure no code has been changed?
I don't know if this will help, but I had to troubleshoot a site for a new client that had been customized heavily with more characters being sent in the query string. If a customer logged in, then every page was an error. If they then cleared their cookies, it was OK for a while. The problem ended up being that there were too many characters being sent in the request header for what the web server configured for by default. We had to change the allowed request length in the registry. Here are some links on it:
MS http://support.microsoft.com/kb/820129/en-us

http://blogs.msdn.com/webtopics/archive ... rrors.aspx
It might help and it might not, but the clearing cookies was one of the clues.

[heinscott]

Thanks Judy, but that's not the problem we're experiencing. In fact, the pages all render correctly... it's just that for some customers, the address defaults to Michigan on the second page of the onepagecheckout (I know it's actually the same page).
Any other ideas??

[jmestep]

No, I just thought maybe something was getting chopped off so the data submitted on the first page wasn't completely getting thru.

[jmestep]

Just thought of this- another site in an older build of Able 7 had a problem with Safari and being able to put certain products in the basket and that is fixed in Able 7.0.2. It had to do with a version of Safari being a web kit. After I applied the 7.0.2 fix to that site, it was OK.

[heinscott]

I've made all the upgrades to the site, and for the past 3 - 4 months, everything has been working fine. It's just been since like last Friday that we started getting calls about this issue...
I've looked through the code, and I can't even figure out where the state could possibly get changed at any point...
Any more ideas please???

[jmestep]

You could use something like Fiddler to check what data is being passed, but you might have already tried that. You just need to have one customer who can replicate the problem every time and what they did so that you can replicate it. As you know, if you can't create the problem it's hard to figure out what is going on. Maybe beg your customer service people to let you talk to the next customer who has that problem.

[heinscott]

I'm not familiar with fiddler, so, yes maybe that would help.
Fortunately, I do have one computer at work that is producing the problem every time. In IE, he cleared the cache, and the problem went away. In firefox, he has not cleared the cache yet, so the problem still exists. What could I do from this to isolate what is causing the problem?
Thanks a lot,

Scott

[AbleMods]

Scott,

Have you looked at anyof the secondary user controls involved on AC7 pages?

For example, several Able functions in their user controls actually search the resulting HTML page for specific controls on the page. Once the control is found, it's contents are modified or manipulated.

Is it possible you added/altered the checkout page to include some user control(s) that it didn't have before? And maybe those new controls are searching the HTML page and manipulating other controls in an unexpected way?

Just a long shot but I could see that having the potential for the issue you are seeing.

The only other thing I can think of is a problem with viewstate. But that would have to be an awfully *specific* problem with viewstate to only mess up the two fields mentioned.....

[jmestep]

Can you post the exact steps to duplicate the problem? What products in the basket, what browser version, etc?
Are you using Able 7.0.2? Your one page checkout looks like an older one because the name is not split to first name and last name. Also, have you checked the field sizes for user agent and checked what his computer is passing as user agent? There have been problems with that because of all the software people have on their computers- the list that is passed in the browser is too long for the field size.

[heinscott]

Joe and Judy...
Thanks for all the help! I really appreciate you both taking the time to help with this.
How would I go about checking the field size for user agent? I can't really put the steps to reproduce the problem, because I'm not sure what exactly causes it. I think it has something to do with people who were shopping on our site during a certain time period, who then came back this last week. We had to add an additional country code last week for a couple of minutes, and I think that this may have caused our new problem.

Scott

[AbleMods]

I thought you said you had one machine that did it every time until the cookie was deleted?

[jmestep]

The fields that have caused errors in the past are all in the ac_PageViews table, so you could increase the size there.
Or you can turn off page logging and test with the machine that has a problem, then turn on the logging again.

[jmestep]

If you think the problem was the country code, you could try an IIS reset to clear the website cache.

[heinscott]

Thanks again Judy and Joe. It turns out (after trying over and over again to try to reproduce the problem), that I could get this error to show up 1) Immediately after being logged on, and then logging out, when.... 2) A customer name is entered that cannot easily be split into first and last name. As such, I just changed the code to reflect the newer version of onepagecheckout that include both first and last name blanks. Don't know why we've never seen this until just this week... guess it could be due to busy season in a pool store.
Thanks for all your help.

Scott