in reply to Cycle through primary key with DBI

Thanks everybody for your advice. I think I see my problem a little better now

From what everybody says, there seems to be a better way to do this -- let me explain what I'm doing:

We have a registration process for users. Users are not really registered until they confirm their registration after they get an email.

So this table that I originally asked about is for the temporary database. I need to give the user a "temporary ID" that he can use when confirming. Only upon confirmation does the user gets a real userid.

The reason for the arbitrary maximum was because we don't have much resource on this particular host machine -- we wanted to keep the data stored there the bare minimum, or at least fixed.

But as I read everybody's advice it seems that simply inserting the new record is the way to go. maybe we'll clean up the table every 2 weeks or so.

However, I still need a way to get the ID -- I will try what Asim wrote later when I get back to it.

If there's better ways to do this, please let me know

This has been most helpful. Thank you all for your help

Replies are listed 'Best First'.
Re: Re: Cycle through primary key with DBI
by asiufy (Monk) on Jun 05, 2001 at 01:43 UTC
    I did something quite similar the other day... But instead of using a temporary table, I set up the normal users table with some extra fields:

    . Validated
    . Validation_Code
    + some others

    So, once the user signs up initially, he's sent the Validation_Code, and his entry in that table reads Validated="No".

    Once he validates himself (by sending back that validation code), just UPDATE his row to read Validated="Yes".

    You can do this using the normal user table, or you can create a secondary table linked to the main one by an ID (since you'll probably want to have a user ID anyway, as the primary key).

    As added "niceties", you can have a field showing how many times the user has attempted to send a validation code. I have a limit of 3 attempts, after that, the user is locked out for good.

    Also, I have a timestamp. After x number of days/hours/etc, I can scan that table and remove all the entries/users that have signed up, but never properly validated themselves.

    Hope this helps...
[reply]

In Section Seekers of Perl Wisdom