Posted by Jerry Stuckle on 04/23/07 16:03

Steve wrote:
> | Actually, David, going to a database won't work any better. You still
> | need to keep the key to the row in the session, and if you lose the
> | session you lose the database info.
>
> you'd only lose db info if the record is deleted or an update was made but
> not committed. the chances of losing a session are present, however losing
> data because of that are nil on the delete side and negligible on the update
> side.
>

No, the data is still in the row. But if you lose the session you lose
the link to the data. It might as well be gone, even if it is committed.

> | If you force them to sign in, you could key the data to their user id;
> | then at least it would be saved when the session fails. But then
> | they'll have to log in.
>
> and when the user logged in again, since the data is in a db rather than a
> session, you could bring them to the last step they completed (whether there
> is already some populated data they hadn't completed or if they're at the
> beggining of that step).
>

And you'll have another session id and another key, unless it is keyed
to the userid, as I mentioned above. But he still has to login because
the session disappeared.

And if the op isn't forcing the user to login, there is no way to sure
way to identify the data.

>
> just a thought.
>
>


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[Back to original message]