A weird sequence

[Alberto]

To avoid the false inserts when the user adds a record and then change the page without clicking on save or cancel I´ve decided to hide the menu in all my forms.
My forms only have the save and cancel buttons.

Supouse to have a form open, lets say in change mode.
The form needs the user to be logged in.
You need to update the exe or theres a problem with internet and the session gets deleted.
You run the new exe or the internet connection goes back and
The user refresh the form page in the browser.

The user does not have a session then the form opens the loginform
The user logs in and what he sees is the original form but empty
The user try to click on cancel or save but it is allways in the same empty form and have no chance to use the system.

I know it is weird but I get this situstion many times when I am programing and closing and running a new exe and may be it could happen to a final user.
How can I solve this problem?
Thanks

[kevin plummer]

Here is what I do

1) You need to update the exe

> I use xfiles to save the sessionQ data to an xml file and then restore that data when the exe restarts.

2) The user logs in and what he sees is the original form but empty

> on insert I save the record and then switch to change mode. I then save each field as it is entered. I actually just do this where there is a parent form and child browse as users would occasionally lose the parent form and the all child records.

[Bruce]

Hi Alberto,

>> To avoid the false inserts when the user adds a record and then change the page without clicking on save or cancel I´ve decided to hide the menu in all my forms.

Your solution is incomplete, and so is largely useless. How do you cater for;
a) the user entering a different address in the address bar or
b) navigating to a different site with a bookmark or
c) just pressing the "back" arrow or
d) closing the browser
e) turning off the machine

or a whole bunch of other activities?

You've removed navigation from the user - and all that's done is force them to navigate another way. Maybe some will now press Cancel, but it's not going to remove the problem 100%, and hence the solution is not going to work.

A better solution is to not care if they Cancel or not.

a) You only have this problem in the first place because you are using auto-numbering. Using a unique string ID removes auto-numbering, so removes the need for the server to "add the parent record before the user clicks save".

b) as mentioned, you only have to do the initial write if there is a "dependent" field on the form - like a child browse. If you can remove the child during Insert mode that's a good option. (it's not always the best user interface though.)

c) you can mark records as "incomplete" until the user clicks on Save. For example, have 3 fields, the "status" (set to 1 when they click on save) - and the date and time of record creation. Now removing "incomplete" records from the database, which are say a day old, becomes trivial.

>> Suppose to have a form open, lets say in change mode.
>> The form needs the user to be logged in.
>> You need to update the exe or theres a problem with internet and the session gets deleted.

There are no "problems on the internet" that would result in a session being deleted. The only way a session is deleted is if it times out. You are in control of the timeout period, so you decide how long that will be.

If you want to stop and start the exe then all sessions are lost (unless you take steps as Kevin recommends - and as I recommend as well.) So, don't stop the server while people are busy. The performance tab will tell you how many sessions are live, and so on.

>> I know it is weird but I get this situation many times when I am programing and closing and running a new exe and may be it could happen to a final user.

Usually I don't allow my final users to stop or start the server exe, so this has never been a problem so far.

cheers
Bruce




You run the new exe or the internet connection goes back and
The user refresh the form page in the browser.