Hi Bryan,

One way might be to increment a stored unique ID integer value in a small, one- or two-column table and return that value as one of the columns included in your ADO recordset. If straight integers don't have enough capacity (about 2 billion keys), I have some code (somewhere -g-) for a "double-incrementing" numeric key value with over 8 billion possible keys that I'd be willing to share.

HTH.


>Sorry for the long message, but I felt some background was in order...
>
>We developed a sweepstakes application that captures approx. 60,000 entries daily. The web app captures generic user information, which we capture, massage and dump to a VFP free table.
>
>A unique id is created with VFP code
>INSERT INTO table ...
>REPLACE id WITH PADL(RECNO()+0,10,"0")
>
>We determine a list of additional questions for the user and includes these and the unique id on the resulting HTML page. The user answers the follow-up questions and submits the data to our app that inserts the data into another free table using the ID as the common field.
>
>NOW FOR THE PROBLEM...
>
>The application was bogging down as we received more and more entries. We decided to try using ASP and ADO to rebuild the application and dramatically reduced demand for memory and CPU. Everything works great except:
>
>We can't figure out how to create the unique user id that is required. We have a temp solution in place using ASP functions...
>
>Randomize
>iLowerBound = 1000000
>iUpperBound = 9999999
>lnRndNumber = Int(Rnd * (iUpperBound - iLowerBound + 1))
>lcGetX_id = String(7 - Len(lnRndNumber), "0") & lnRndNumber
>
>This id gets INSERTed along with the first data dump, included on the second HTML page and dumped with second data dump.
>
>This is obviously not the best method. What is the best method to accomplish this? We've thought of a database container with a trigger, but how do we get the unique id back to ASP using the ADO object? Other suggestions?