Rob wrote on Wednesday 22 October 2003 10:07:
You could base the number on the Unix time stamp. That would always be
unique (since it's just one long string of seconds since 1970). Then
append
that number with some other identifier (IP address, User ID, etc) Then,
when they hit "submit", just save it.
Using that method would also automatically give you the date/time that the
request ticket was created; all you'd have to do is parse and decode the
first part of the request ticket.
That wouldn't work for simultaneous users who are using a proxy server.
i.e., if at any point that app was used by 2 or more users simultaneously
under the same proxy, it would have to use a different logic for generating
unique IDs.
One that I've seen and used a lot is similar to (or expanding of) what
Sanjay suggested with the difference that there's many numbers and they are
all stored in a database table.
So, you have a table:
uniqueid
----------
id
and a few number records (depending on user load) like:
150, 151, 152, 153, 154, 155
When you want a new ID, you grab the lowest ID (150), delete it, and insert
a new one at the end (156). Sometimes, and depending on database platform,
it is recommended to use transactions, as well as row-level, page, or table
locking to handle [rare, depending on the user load] truly simultaneous
requests.
This is a brief comment. There are some views and papers published on this
by experts. I'm sure if the OP searches, he will find some nice ways to
accomplish this.
--
Business Web Solutions
ActiveLink, LLC
www.active-link.com/intranet/