A Connection object defines a connection to a database. DataObjects for .NET supports database access through OLE DB, native database access for SQL Server and Oracle, and also any other (custom) .NET data providers, see Native and OLE DB Database Access.

Although, in most cases, a schema contains a single database connection, it is possible to have multiple connections in a schema. To create a connection, click the Add button and choose a connection type or select Add from the context menu in the Connections window of the Schema Designer.

You can also add connections using Import database structure or Connect to database in the Schema menu (see Importing Database Structure for details).

Connections are stored in the Connections property of the Schema object. The list of available connections is shown in the Connections window of the Schema Designer.

Each simple table has a Connection property associating it with a certain database connection. Together with the DbTableName property, it determines the database table on which this table is based (if any, see Simple Tables for details).

DataObjects for .NET uses Connection objects to perform database access operations, fetch and update on the server, freeing developers from the tedious task of writing database access code. Database access is performed automatically by DataObjects for .NET, and it can be customized with user code in appropriate business logic events, see How the Data is Fetched and Updating the Database. A Connection object also serves as transaction context. Performing database updates, DataObjects for .NET opens a separate transaction for each connection involved in the operation. In the case of multiple connections, these transactions are managed together in a consistent way, They are either committed or rolled back together, so the whole update operation is performed consistently, as a single, possibly heterogeneous (spanning multiple databases) transaction.

Having multiple connections in a schema allows you to easily switch between different physical databases storing the same logical data, without changing anything else. This is possible both at design and at run time. All that is needed is to change the Connection property in DbTable objects. At run time, it can be done either in the CreateSchema event or using the DynamicConnections run-time property.

Sometimes Connection objects must be changed at run time, to set a specific database location, user ID, password, connection timeout, or other attributes of the ConnectionString. The ConnectionString contains all necessary information to make a database connection. Changing it at run time allows you to adjust that information dynamically. Changing ConnectionString and other connection properties can be done at run time using one of the two methods: in the CreateSchema event or using the DynamicConnections property. In the CreateSchema event you can change any part of the schema, including connections, but that is done only once for the whole application when the data library is initialized. If you need to change ConnectionString or other connection properties several times or on a per-data set basis, use the DynamicConnections property of C1DataSet.

You may also need to change the ConnectionString at run time for security reasons, because you do not want to expose User ID and Password information to all clients of the data library. A frequently used technique is to clear the ConnectionString in the Schema Designer before you deploy the data library and use the DynamicConnections property to specify the ConnectionString at run time.

To edit a connection, double-click the connection object in the Connections window to open the Connection Editor.

Here you can edit the ConnectionString, either manually or in the standard Data Link Properties dialog box. Also in the Connection Editor, you can specify SQL syntax rules, properties of the SqlDialectInfo object. These properties determine various specifics of SQL syntax relevant to DataObjects for .NET that can vary between different databases. Normally, these properties are set automatically to their appropriate values when you specify ConnectionType or ConnectionString, but, occasionally, they may need manual adjustment, for example, when using a third-party OLE DB provider or a custom .NET data provider.