For a converted multi-tenant database, any existing application only requires the default tenant in order to execute as originally designed, and you typically add additional regular tenants to expand the application to run with totally separate sets of users, again, with little or no change to the application code.

If you already have domains defined in a converted database in order to sign on users using a client-principal object, and you configure each of these existing domains with a tenant, your application might work without any further changes depending on how you initialize attributes of the client-principal. Assuming these attributes are set correctly, existing calls to the SET-DB-CLIENT function or the SET-CLIENT( ) method (on the SECURITY-POLICY system handle) will set the user tenancy along with the user identity of any multi-tenant database connection.

If your user login procedure relies entirely on the User ID (-U) connection parameter to authenticate database access (at startup or using the CONNECT statement), as long as you ensure that users provide a user ID that includes their assigned user name and domain name in the form, user-name@domain-name, and the domain is configured for an authentication system (such as the _User table accounts) to which OpenEdge can authenticate database connections, your application might also work without any further changes. The main thing is to ensure that your application sets database connection identity in a manner that authenticates users with a tenancy defined in your database.

You can design a number of different approaches (authentication models) to manage user access to OpenEdge databases. For more information on authenticating users in both multi-tenant and non-multi-tenant environments, see OpenEdge Getting Started: Identity Management and ApplicationSecurity .