Losing Data Between Calls

[Chris Kelleher]

Hello all,

I have just launched my first webspeed app (www.labbb.org) and am getting
pretty good results but have a little problem with about four percent of my
users.

The application is for the Better Business Bureau in Southern CA, and the
problem arises in the Complaints module.

In order for a user to file an online complaint he works through a series
of screens. A personal-information form is filled in first, the contents
of which are stored in hidden fields and passed along, throughout the
process. After the PI form, a user searches for the company in question
which leads through a few filtering screens to isolate the exact company.
Once identified the company ID is placed in a hidden field too. This leads
to the actual complaint form where the substance of the complaint is
entered. Once done, the user goes to a proof-read screen where all of the
data from the hidden fields is pulled up and combined with the complaint
data and shown to the user for review before it is submitted.

What's happening with my four percent is that all of the data in the hidden
fields is being lost mid-way through the process. It is always and the same
page. The data comes in but doesn't come out, according to the logs.


My solution to the problem is to do some redundant data checking at the end
of the process and use cookies to restore the lost data, which should cover
most of the four percent, and in those cases where the cookies aren't
available, display a "process-failed" screen and direct the user to retry
the process. This will work pretty well, but it bothers me that I don't
understand why it's failing in the first place.

The internet server is an x86 machine running NT4.0, Apache for Windows and
WS 3.0 which works against a 8.2 Progress db running on SCO 5.5 Open Server.

I imagine that it could be any number of things causing this problem:
network problems, user browser settings, problems with the WS
configuration...

Does anyone have any insight as to what might be causing this problem?


TIA,
Sean Olson
solson@bbbla.labbb.org

 

[Chris Kelleher]

What about programmatic errors?

Seriously, I just looked at the app. Passing all those
values around from page to page via hidden fields is asking
for a logic error somewhere. I made it to the "company
search" page, submitted it, then waited until the browser
finally timed out your connection to the webserver. I have
to assume that it is your query logic for "searching" that
is the problem here because I could still access your WS
Workshop (BTW, you should never put a production app out
there and have that Broker in "development" mode).

You really should change the architecture of how data is
passed/accessed between web requests.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
R o b e r t J. M i r r o
rmirro@microserve.net http://www.microserve.net/~rmirro/

I can't sleep beneath the trees of wisdom
When your ax has cut the roots that feed them
Forked tongues in bitter mouths
Can drive a man to bleed from inside out
- Creed
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Chris Kelleher]

Unfortunately, all of this is an academic exercise as our connection to the
internet is down right now. But I would still appreciate any feedback.


>I'm not sure I understand how you construct this log file though.
>How are you testing "what comes in" and "what goes out"?

On the Apache log file, Access.log I am able to see the data as it's passed.

>What about programmatic errors?

>You forgot a likely suspect, the code. You'll need to provide
more info, the code of this page in particular.

I am looking at this now. The break always comes within the same three
pages.

Page One takes the user input from a company search form and builds a record
set of possible matches which could range from 0 to more than 100 depending
on how much, how distinct, and how accurate the input is. A Temporary Table
is used to hold the record set while all potential matches are ranked and
ordered. The record set is then displayed in a kind of green-bar format,
each with it's own link and dynamically generated query string. This string
combines the Personal Information form the first form with the that
company's particular ROWID. All of this is passed to the second page.

<BLOCKQUOTE><font size="1" face="Arial, Verdana">code:</font><HR><pre>
&lt;a
href="CVrfyFrm.html?hCoRowID=`tCompany.tROWID`&hCPre=`vCPre`&hCFName=`vCFNam
e`&hCLName=`vCLName`&hCAddr=`vCAddr`&hCCity=`vCCity`&hCState=`vCState`&hCZip
=`vCZip`&hCCountry=`vCCountry`&hCPhone=`vCPhone`&hCFax=`vCFax`&hCEMail=`vCEM
ail`"&gt;
[/code]

I can see this being passed to the verification form via the Apache log.


Page Two takes up all of the string via the get-field function, after all of
the variables have been defined, and assigns the values.

<BLOCKQUOTE><font size="1" face="Arial, Verdana">code:</font><HR><pre>
vCPre = get-field("hCPre").
vCLName = get-field("hCLName").
vCFName = get-field("hCFName").
vCAddr = get-field("hCAddr").
vCCity = get-field("hCCity").
vCState = get-field("hCState").
vCCountry = get-field("hCCountry").
vCZip = get-field("hCZip").
vCPhone = get-field("hCPhone").
vCFax = get-field("hCFax").
vCEMail = get-field("hCEMail").
[/code]

I then use the ROWID to locate the company record and assign its primary
key.

<BLOCKQUOTE><font size="1" face="Arial, Verdana">code:</font><HR><pre>
FIND company WHERE rowid(company) = TO-ROWID(get-field("hCoRowID")) NO-LOCK
NO-
ERROR.
IF AVAILABLE company THEN vCompID = company.comp-id.
[/code]

BRAIN FLASH!!!!!!!!!!!

****All of this takes place in the HEAD of the document...Could this be the
source of the problem?***


What the user sees is a display of the full company record, name, full
address, and so on. This is done to make sure that in complaint is filed
against the proper entity.

Under the covers, in the body of the document, all of the values are
repacked into hidden fields that are then passed on to the complaint form
once the consumer verifies the company.

<BLOCKQUOTE><font size="1" face="Arial, Verdana">code:</font><HR><pre>
&lt;INPUT TYPE="HIDDEN" NAME="hCPre" VALUE="`vCPre`"&gt;
&lt;INPUT TYPE="HIDDEN" NAME="hCFName" VALUE="`vCFName`"&gt;
&lt;INPUT TYPE="HIDDEN" NAME="hCLName" VALUE="`vCLName`"&gt;
&lt;INPUT TYPE="HIDDEN" NAME="hCAddr" VALUE="`vCAddr`"&gt;...and so on
[/code]

This is where the data disappears in about four percent of the cases.

It goes to the complaint form from here.

As I have written this out, it does occur to me that the problem may be the
structure of the verification page. I will bring everything down into the
body of the page and see if that changes things. In the mean time if anyone
has any suggestions they would me very welcome.


TIA,

Sean Olson
solson@bbbla.labbb.org

 

[Chris Kelleher]

Just a wild guess, could the query string be too long?
Have you tried submitting the form using method="post" instead of get?

 

[Chris Kelleher]

That's a good guess, but I don't think it applies here. If
that was the case, the web server would have crapped out with
414 Request-URI Too Long error.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
R o b e r t J. M i r r o
rmirro@microserve.net http://www.microserve.net/~rmirro/

I can't sleep beneath the trees of wisdom
When your ax has cut the roots that feed them
Forked tongues in bitter mouths
Can drive a man to bleed from inside out
- Creed
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Chris Kelleher]

Just a closing note on this issue,

&lt;Tongue In Cheek&gt;
Even though this acknowledgement may lessen my value within the
community I have to make a public
confession.
&lt;/Tongue In Cheek&gt;

The problem lay in the absence of a closing quote on the ACTION attribute of
the FORM tag on the verification page. This is what caused the intermitant
behavior.

MY BAD!

I do appreciate all of the feedback and have gained some other insights that
will guide me as I revise this app.


Best Wishes,

Sean Olson
solson@bbbla.labbb.org