Temp-tables have no inherent tenancy and do not automatically store the tenancy of multi-tenant data that might be queried to populate them. So, if your application relies on temp-tables that are populated from a multi-tenant database, especially in ProDataSets that are used to transport data through the layers of an application modeled on the OpenEdge Reference Architecture (OERA), or across the ABL sessions of any multi-tier or service-oriented application, you need to explicitly track the tenancy of the data, unless tenancy is implied in the application data itself.

Without a clear indication in the application data, you can add columns to explicitly identify the tenancy in any temp-tables that hold multi-tenant data.The maximum additions you might need to track the tenancy of data are columns sufficient to store the tenant name, tenant ID, and the name and path to the database where the data originates or is intended for update. If only one database is involved, you might need only one column to store the tenant name or ID.

You might also find other ways to identify the tenancy of data that is transported to and from its source, such as by using class or procedure-based objects instantiated to handle the data for specific tenants.