autoincrement primary key

[Ingmar]

When I design database table outside of LANSA, I always use a primary key that’s an integer, which is set to autoincrement, generated automatically by the database.

However, I can’t seem to be able to that with LANSA.

I went through the examples and it seems that most of the examples use a primary key that is part of the domain model (e.g. employee number, department code). Also – I noticed there RRN, but that can’t be made into a primary key.

So – is there a “proper” way of setting up an auto-generating, auto-increment primary key, in LANSA-defined tables?

I know that we can of course generate the value ourselves from the server module e.g., but that just does not feel right). Is there a way to do that at the IO Module level?

[atostaine]

You can use System Variables. i agree we need a way to duplicate the sql auto identity feature in the repository.

[jyoung]

Look into the *AUTONUM System Variable.

http://docs.lansa.com/14/en/lansa015/in ... 4_0110.htm and http://docs.lansa.com/14/en/lansa015/in ... e8_002.htm

Basically you end up creating a new System Variable with a name that starts with "AUTONUM" then a specific convention that specifies the length of the number and unique name for the data area.

Capture.PNG (9.92 KiB) Viewed 11692 times

Then, before you insert the record you assign your "identity" field to the System Variable.

Code: Select all

#MyNumId := *AUTONUM10MYNUMID

It should be noted however, that system variables are across all partitions so if you are working in a multiple partition environment, your system variables for your files in one partition will be available in the other partitions.

I agree with the others that a identity field would be nice.

[MarkD]

I am a big fan of using *GUID as a unique identifying key.

http://docs.lansa.com/14/en/lansa015/in ... 4_0120.htm

The value is unique so there are no issues with duplicates, even across multiple server databases and networks.

[HMJust]

Having spent many years in an environment where we used an integer identity field I too have come to prefer GUIDs. While integers are easy in many ways, the uniqueness across installations and files of GUIDs make them more suitable over time.