The UIDGenerator table Framework table 

Orixa databases use an unique integer (whole number) to identify every record in the database. This system is driven from a Framework data-table "UIDGenerator" in the SystemDB database. The setting values in the UIDGenerator table allows an administrator of an Orixa system to set unique ranges of integers for different instances of Orixa databases in multiple instance versions of the system.

The UID function defines all primary keys in Orixa data-tables

Look at the following Orixa table definition:

CREATE TABLE "People"
(
"ID" INTEGER DEFAULT UID() NOT NULL,
"FirstName" VARCHAR(40) COLLATE "ANSI",
"LastName" VARCHAR(40) COLLATE "ANSI"

Note the first line: 

"ID" INTEGER DEFAULT UID() NOT NULL

This shows that whenever a new record is added to the database, the first field in the data-table, called "ID" is given a value by the UID() function.

FUNCTION "UID" ()
RETURNS INTEGER
BEGIN
  DECLARE Crsr CURSOR FOR Stmt;
  DECLARE Result INTEGER DEFAULT 1;
PREPARE Stmt FROM ' SELECT UID FROM SystemDB.UIDGenerator ';
OPEN Crsr;   
FETCH FIRST FROM Crsr ('UID') INTO Result;
CLOSE Crsr;
EXECUTE IMMEDIATE
  ' UPDATE SystemDB.UIDGenerator SET UID = UID + 1 ';
RETURN Result;
END

If you read this function you will see that it returns the value of the COLUMN called "UID" from the UIDGenerator table, and then increments the value by 1.

Through this simple method every new record in the Orixa database is given a unique number, in order. This is a useful feature, as it allows the administrator and all users to see the "age" of any record compared to all the others in that instance of the database.

UIDGenerator framework table  

1. SystemDB for an Orixa system. This is used to hold a small number of Framework data-tables which are used to control Orixa Apps.
2. UIDGenerator table.
3. The table (usually) consists of a single row of data. The critical fields are the "UID" and the "NextMaxUID". The UID is used to return Unique ID values for rows in the Orixa database. The NextMaxUID marks an upper limit. Above this the database will stop allowing the addition of new rows, until a new UID range is created. The upper limit exists because an Orixa system may include multiple instances and each of these needs its own "UID Range".

Managing UIDs in a multi-instance Orixa System

The Developer managing such systems should keep a log of the UID ranges they have released for different database instances. UID ranges should be generous, it is normal for an UID range to be one million records, and for larger systems it can be more than this. The key thing is that no two instances of the same system should have the same UID ranges, or when data is replicated between the instances data-conflicts may occur.

How to know the "UID Ranges" already in-use in a multi-instance system

The following SQL:

SELECT
  DISTINCT(ROUND(ID / 1000000 TO 0)) as UIDRanges,
  ROUND(COUNT(*) / 10000 TO 2) as Fullness
FROM EditHistory
GROUP BY UIDRanges

Returns a data-table which shows which UID Ranges are present in the EditHistory framework data-table.

The numbers are divided by one million and rounded, to show which one million record wide UID ranges have been used. As every insertion of a record into a data-table in Orixa is recorded by adding a record to the EditHistory framework data-table, if a number is present in the result set from this query, that means the UID range starting from that number of millions is in use.

By the same logic, any missing number indicates that that range is not in use, and can be used as an UID range. Note that ranges with a low "Fullness" have only been used for a few records. It may be worth checking whether computers using these ranges are still in use.