If you capture (and compare on future hits) their username and IP address, you could probably come up with enough logic to make sure they are who you think and they can only see their own records.

This would mean some validation on each hit, but your key values could [potentially] remain simple.

Guy


>The following is a requirement that I am sure many of you have had a need for and I would be interested to know how you have solved it:
>
>We need to provide our clients a URL to an HTML report module. The module requires a unique Job ID (for example, http://domain.com/r.asp?JOBID=xxx). Although the table's primary key would be perfect for this situation, someone can substitute this number with another and retrieve another client's reports.
>
>In a search for a non-guessable primary key, I considered using a uniqueidentifier field. The one disadvantage of that option is that the URL will be very long. Although the initial table has its own primary key, the Job will be located by searching for the uniqueidentifier provided.
>
>My questions are:
>1. Is that a major load to the DB (because of the lenght of the field)?
>2. Has anyone else used a different approach?
>
>PS: there are too many clients to create logons for each one every time a new order is placed.
>
>Thank you,