Hi Alex,

You don't have to, if it suits you.
You can have supporting table with two fields: the table name and integer key field that holds the key. There's also associated stored procedure that increments and updates this key and returns key value to the calling program.

CREATE PROCEDURE GetNextKey 
  @TableName  char(32)
AS
set nocount on
declare @NextId int
UPDATE KeyTable SET 
  @NewID = LastKey
  LastKey = LastKey + 1,
WHERE TableName = @TableName
SELECT @NextId 

>It seems hard to give up such a powerful concept as identity columns, but I know you have lots of experience. Can you be more specific about the "similar approach" that you use? Thanks.
>
>
>>I personaly, use an approch similar to that because I like to be in control of PK generation.
>>
>>>Great! thank you - I'm reading the article now.
>>>
>>>>>Perhaps this is not the best place to post a SQL Server question, but here goes anyway...
>>>>>
>>>>>In VFP, I commonly insert parent and child rows into tables by first generating a primary key value for the parent table and then using that as the foreign key value for the child rows. This way, of course, the child rows are properly related to the parent.
>>>>
>>>>An article at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnfoxtk00/html/ft00l1.asp shows how you can do the same on Sql Server.
>>>>