As noted previously (see the What is Multi-tenancy? on page 1), after converting a non-multi-tenant database to a multi-tenant database, most, if not all, of the code in an existing ABL application will work without change. When executing against a multi-tenant database, all existing ABL code that accesses database objects is implicitly tenant aware, which means that it accesses database objects that are shared (non-multi-tenant) or that belong to the tenancy of the connected user (if you have made any database objects multi-tenant).
Super-tenant users run a converted ABL application without any real tenancy of their own, which means they can access shared data and, potentially, the data for one or more effective regular tenants. Initially, OpenEdge sets the effective tenancy of all super-tenant users to the default tenant, whose data super tenants can access by default. To enable super-tenant access to data regardless of tenancy, ABL provides additional features that you can use in both existing and new applications.
If you plan to create tenant groups for multi-tenant tables, or use any shared (tables, and are also considering the use of multi-tenant sequences, you need to plan carefully because of the way multi-tenant sequences interact with any tables that are shared by multiple tenants.
The following sections provide a general overview of all the ABL features that multi-tenancy enables:
For more information on coding for super tenancy and other issues with coding for multi-tenant databases, see the sections on multi-tenant ABL in OpenEdge Development: Programming Interfaces.
