>I need to receive more wisdom from all you surrogate key experts out there. What do you think of the Tastrade sample app's way of making them? That is, apart from the fact that it uses a character field, which is easy enough to change. To refresh our memory, the Tastrade database has a table called "setup" whose fields are the names of tables having keys, and the next unused value for each key. The primary key of each table has a default value newid(), which is a stored procedure that looks like this:
>

>FUNCTION NewID(tcAlias)
>  LOCAL lcAlias, ;
>        lcID, ;
>        lcOldReprocess, ;
>        lnOldArea
>
>  lnOldArea = SELECT()
>
>  IF PARAMETERS() < 1
>    lcAlias = UPPER(ALIAS())
>  ELSE
>    lcAlias = UPPER(tcAlias)
>  ENDIF
>
>  lcID = ""
>  lcOldReprocess = SET('REPROCESS')
>
>  *-- Lock until user presses Esc
>  SET REPROCESS TO AUTOMATIC
>
>  IF !USED("SETUP")
>    USE tastrade!setup IN 0
>  ENDIF
>  SELECT setup
>
>  IF SEEK(lcAlias, "setup", "key_name")
>    IF RLOCK()
>      lcID = setup.value
>      REPLACE setup.value WITH ;
>              STR(VAL(ALLT(lcID)) + 1, LEN(setup.value))
>      UNLOCK
>    ENDIF
>  ENDIF
>
>  SELECT (lnOldArea)
>  SET REPROCESS TO lcOldReprocess
>
>  RETURN lcID
>ENDFUNC
>
>

>
>Does it look secure? I'll probably do it this way unless someone sees a problem. Thank you.

Looks pretty good, Bret. I would store a numeric value, even if I were using a character value in my tables (in VFP3 I use a character field with the numeric value padded with 0's)

You might consider adding a 'pause' in the reprocess loop. Networks can actually slow down when several people send multiple lock requests close together. Maybe add an inkey(.1) or inkey(.05) to the loop.

Barbara