Re: Design pattern for preventing the assignment of duplicate login id's
From: MattC (m_at_m.com)
Date: Tue, 17 Aug 2004 14:18:10 +0100
Then go with your orginal idea of keeping the userID of those in the wizard
in your application object.
Personally I'd leave the userID selection till the end like Hotmail does I
believe, that way you have all your wizard info in the session and you can
keep redirecting them back to the final page if they continually pick used
userid's, until they pick one that is unique and the wizard is then
But if your requirement is that it has to be at the beginning then you will
have to manage which names are being used.
"Itai Itai" <email@example.com> wrote in message
> "Also if they go away without completing and never come back you know
> this by the active field being false. You can free up usernames by
> frequently deleting inactive entries over a certain date ago."
> My solution prevents this by committing the name to the db only upon
> successful registration.
> Furthermore, I don't do multiple updates to the database but only one
> which commits entire user details upon successful wizard completion.
> Review the solution for further details.
> *** Sent via Developersdex http://www.developersdex.com ***
> Don't just participate in USENET...get rewarded for it!