Row ID Generation

Here is an explanation of how row_id’s are generated:

Siebel allocates blocks of 100 row_id’s to a session when required. Each new session that requires to generate a row_id is given it’s own block of 100 row_ids.

Example: Try the following: Log into 4 sessions, or sequentially log in and log off so that a new session is created each time. Then create a record in each session and look at the row id generated. If the beginning row_id is 1-APW7H, then next available row_id’s in succession are 1-APWA9, 1-APWD1, 1-APWFT which are 100 block increments.

The following steps occur during your session:

1) A Siebel session requires to insert a row (the first time). Therefore from table s_ssa_id, it retrieves the corporate_prefix (which is currently set to 1 and the next_suffix, in this case APW7H and updates the next_suffix field to APWA9 as the next available suffix, which would be the 101th id.

2) The row_id is created for use during your session as follows: “corporate_prefix” || “-” || “next_suffix”, which gives “1-APW7H”

3) For each additional row_id required, the next_suffix is incremented for your session as follows. The last position is incremented using the sequence (0-9, A-Z). Once “Z” is reached, the next position is rolled over using the same sequence and so on.

1-APW7H

1-APW7I

1-APW7J

:

1-APW7Z

1-APW80

1-APW81

:

1-APW89

1-APW8A

:

1-APW8Z

1-APW90

:

1-APWA8

4) Once your block of 100 row_id’s are exhausted, your session will retrieve the next block available.

If you copy data across environments, you could increment the value of column corporate_prefix in table s_ssa_id (in your development/testing environment),

from 1 to 2, then all new row_id’s would be of the format 2- XXXXXX. That would eliminate any potential duplicate row collisions.