At 03:59 PM 06/13/2002, Brett Sanger wrote: >>Another way to handle this is to have a two-part submission. The >>first form creates a recrod in the database, but somehow marks it >>as unconfirmed. You then return a confirmation form with the key for > >I listed my objections to this earlier: it clutters up the database >with unfinished "unconfirmed" entries. This may or may not be >acceptable. In the case where the potential problem in the first >case _is_ a problem, this is almost certainly the way to >go. Likewise, if you have a problem with abandoned unconfirmed >entries, go with the first solution. (OTOH, Marketing people _like_ >the unconfirmed entries, because it gives them data about people who >show some level of interest but are unwilling to commit.
One way to mark something as unconfirmed is to place it in an "unconfirmed" table, and then the confirmation moves it to a "confirmed" table. This prevents the problem with gaps in the key sequence in the confirmed table. It does require that you clean out old entries, but this is the only method I have come up with that meets the requirements of: absolutely no unintentional duplicate submissions, absolutely no lost submissions due to the duplicate submission checks, absolutely no gaps in the key sequence of accepted submissions. -- Greg Marr [EMAIL PROTECTED] "We thought you were dead." "I was, but I'm better now." - Sheridan, "The Summoning" --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
