At some point, you *will* hit a duplicated session ID, even if you only generate them infrequently. Sure, the chance is very very low, but it's still there.

If you are generated unique ID for session management, a good way to guarentee is to use a combination of random characters, the time(), some counter (as to handle the very rare cases when two new sessions are started at the same time()), and possibly but not necessary some identify from the user ( but do not rely solely on this piece of info for user identification ). You should also hash this as to have some checksum characters in there to make sure that the key isn't randomly being guessed at. With the combination of time() and a counter, you can guarentee that every session ID you generate is unique (or at least until the 32-bit clock wraps around... :-).

Of course, the other option, if you don't want to rewrite your code, is that upon generation of your completely random key, store that away in a database, with a frequent purging of keys that are no longer in use (say, after a few hours after being created). When you create another new key, just check to make sure that it doesn't exist already, and if it does, just generate a new one and recheck.

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important