This tutorial describes how to build ODP.NET, Managed Driver applications. You will learn:

• How to develop a basic ODP.NET, Managed Driver application from start to finish
• How to deploy ODP.NET, Managed Driver applications, which have notable differences from ODP.NET, Unmanaged Driver application
• How to use ODP.NET, Managed Driver from Oracle Developer Tools for Visual Studio
• How to convert an existing unmanaged ODP.NET application to a managed ODP.NET application

This tutorial covers how to use Multitenant Container Databases in Visual Studio.

The Oracle Multitenant option is introduced in Oracle Database 12c Release 1 to enable an Oracle database to function as a multitenant container database (CDB) that includes zero, one, or many customer-created pluggable databases (PDBs). A PDB is a portable collection of schemas, schema objects, and nonschema objects that appears to any Oracle client application as a non-CDB. Note that all Oracle database versions prior to Oracle Database 12c Release 1 (12.1) are known as non-CDBs.

PDBs can be created quickly from a seed pluggable database or cloned from another pluggable database. These operations are much faster than creating a non-CDB database from scratch. Pluggable databases can also be unplugged, resulting in a set of database files and an XML metadata file that can be plugged into other container databases.

For developers, this feature makes testing a database configuration with your application as simple as cloning an existing PDB, or plugging in a PDB in the form of some provided database files. Similarly, a pluggable database can be shared with other developers, either by cloning or through unplugging and sharing the database files. At deployment time, a development PDB can simply be unplugged from the development container database and plugged into the production container database.

Schema Compare is an integrated tool that is included with the Oracle Developer Tools for Visual Studio (ODT). It is used to visually inspect the differences between a source and a target schema and to generate a diff script that modifies the target schema to make it identical to the source. The source and target schemas can reside on the same database or on two different databases.

Developers will typically evolve their development schema as they work on their .NET application, for example creating or modifying tables or stored procedures that are used by their .NET application. During development, they can use the Schema Compare tool to visually inspect what changes have been made thus far, and when development has completed, they can use the tool to generate the deployment scripts for synchronizing the development and production schemas.

This OBE walks through a general use case scenario of a .NET developer. It consists of the following steps:

1. Start with a development schema identical to the production schema. We will create two schemas named DEVELOPMENT and PRODUCTION and they will both contain a portion of the HR schema.
2. With the progress of the .NET application, the development schema evolves to meet the needs of the application
3. During development, use the Schema Compare tool to compare the development versus production schemas and view the differences
4. On the completion of the development, use the Schema Compare tool to compare the development versus production schemas and generate the diff scripts and rollback scripts
5. Deploy the diff script to bring the production database up to the required version of development schema
6. Apply the rollback script to roll back the changes made to the production database.

We will use the Schema Compare tool to identify, synchronize and rollback the differences in the created instances.