Secure a unique ID before inserting into DB

[luc wastiaux]

Hello,
I am writing an application to handle support requests, and the user
needs to have his request number printed out in front of him even before
he hits the "submit" button. I have no idea how to secure a unique
number without relying on a database.
How could this be done ?

thanks.

--
luc wastiaux - email: [email]dustpuppy@airpost.net[/email]

[rush]

> I am writing an application to handle support requests, and the user

> needs to have his request number printed out in front of him even before
> he hits the "submit" button. I have no idea how to secure a unique
> number without relying on a database.
> How could this be done ?

how about inserting a record before submit? In other words, you have php
file that displays form to enter request. Before you do anything in that
file insert a record, and put in some column of it something like
"finalized='F' ,and then display form now that you know the Id.

Then when you process submit, just update the existing record, and turn
"finalized='T'".

rush
--
[url]http://www.templatetamer.com/[/url]

[s a n j a y]

or you can store a number in a file and everytime you need to display the
page read it, increment it and save the file. Its something like doing page
view counters.

sanjay


"rush" <pipa@rush.avalon.hr> wrote in message
news:bn32u2$8h6$1@ls219.htnet.hr...
| > I am writing an application to handle support requests, and the user
| > needs to have his request number printed out in front of him even before
| > he hits the "submit" button. I have no idea how to secure a unique
| > number without relying on a database.
| > How could this be done ?
|
| how about inserting a record before submit? In other words, you have php
| file that displays form to enter request. Before you do anything in that
| file insert a record, and put in some column of it something like
| "finalized='F' ,and then display form now that you know the Id.
|
| Then when you process submit, just update the existing record, and turn
| "finalized='T'".
|
| rush
| --
| [url]http://www.templatetamer.com/[/url]
|
|
|

[Rob]

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.

Here's a base reference. Look at all the date/time references in the PHP
manual as well.

[url]http://www.phpfreaks.com/quickcode/How_to_Generate_a_Unique_ID_for_Order_Tracking_Num bers/17.php[/url]




Rob


"luc wastiaux" <dustpuppy@airpost.net> wrote in message
news:bn2sjn04hm@enews4.newsguy.com...

> Hello,
> I am writing an application to handle support requests, and the user
> needs to have his request number printed out in front of him even before
> he hits the "submit" button. I have no idea how to secure a unique
> number without relying on a database.
> How could this be done ?
>
> thanks.
>
> --
> luc wastiaux - email: [email]dustpuppy@airpost.net[/email]
>

[Zurab Davitiani]

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
[url]www.active-link.com/intranet/[/url]