Friday, June 02, 2006

The beta tester and the ghost bug

It's been a long debugging day today.
Everything started yesterday evening, when i got a phone call of an employee saying:
"I entered 50 records in the afternoon, but i just logged in the application now and they are all gone!"

So, i logged in to see what's wrong and oops! No data to display, nothing, nada de nada.

Needless to say, i seriously began to be worried about it.

I felt much better when i found out shortly afterwards that the data hadn't vanished at all, they were right there. It was just the application that was displaying nothing.
But why on earth it's displaying nothing if the data are right there?

Well, i'll investigate tomorrow i thought.

Then tomorrow arrived and i started an endless mail exchange with John at Shellprompt.net where my Oracle Application Express based sites are hosted.

I started examining the Oracle Apex active session log and soon it became clear to me i had a problem with the so-called application level items.
There were a couple of those global variables that were not initialized and, to make it worse, this was happening erratically.
Sometimes the values were there, sometimes they were not.

To make the story short, we logged in and out dozens of times, for six straight hours, without making any progress, every solution we tried was failing in the end.

Until John saw the light.

The problem was in the conditional process running after the page submit.

Items were initialized after that the user submitted the page by pressing the login button. Or at least that was my understanding of the user's behaviour.

The password field in the login form is not a simple text field.
It carries an additional property, the automatic submit in case the user presses the enter key.


And in this case there is going to be no login button event ever.

No button, no event, no process, no initialization.
It was sufficient to remove the conditional clause based on the login button event from the application items initialization process definition and the nightmare was finally over.

This story tells me how long it can take to fix a problem if you do not focus early on every tiny detail of the puzzle, including how the user interacts with the programs. Moreover if you are a user too, your understanding of the problem is heavily biased by your personal experience: i am using the mouse most of the time, while others are using the keyboard to do the same operation.

And now just let me thank John once more for his invaluable and continuous support.

1 comment:

Colin Sheppard said...

On the same topic, watch out for the 'Logout URL' in the authenication scheme of your app:

wwv_flow_custom_auth_std.logout?p_this_flow=&APP_ID.&p_next_flow_page_sess=&APP_ID.:1

The bit in question is the return page of '1'. If you application does not have a page 1 or the logout ending should really go somewhere else, you will get problems.

For example, I lacked a page 1. So when I logged out, I went to page 101, logged in, and went to page 1. It gave an error. However, second time round I was successful. (My really target page was &P101_HOME_PAGE., as determined by a processes.)

So beware!

yes you can!

Two great ways to help us out with a minimal effort. Click on the Google Plus +1 button above or...
We appreciate your support!

latest articles