> Another problem is that this will prevent the user from backing up to > the form after it was submitted, changing the values slightly, and > submitting again for a slightly different entry, which should still > be unique. There may be cases where this is acceptable, and yours
This would also fail under my suggestion. As Greg points out, in some cases this isn't a problem, and in others it is. > 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. > entry. This will require some additional maintenance as unconfirmed > entries will have to be cleared out after some timeout period. As he said, you can, of course, clean house. --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]