This chapter describes how ABL supports multi-tenancy. For an overview of multi-tenancy, see OpenEdge Getting Started: Multi-tenancy Overview. For existing applications written for non-multi-tenant databases, there is often no difference in the ABL required to run with multi-tenant versions of the same databases. That is, 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 converted 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 (the default) or that belong to the tenancy of the connected user (if you have multi-tenant-enabled any database objects).
Super tenant users initially run an existing ABL application as the default regular tenant, which means they access only shared data and data owned by the default tenant. To make full use of super tenancy, which allows access to all the data in a multi-tenant database regardless of tenant ownership, ABL provides new features that you can add to existing applications or use to build new applications. These features allow a super tenant user to query and update the data owned by any one tenant, or group of tenants, defined in the database.
If you plan to create tenant groups for multi-tenant tables, or use any shared (non-multi-tenant) tables, and you also are considering the use of multi-tenant sequences, you need to plan carefully because of how multi-tenant sequences interact with any tables that are shared by multiple tenants.
