.daConfig File

All Data Abstract server applications require a well configured DataAbstract.daConfig file to be loaded at start up. This XML file provides information on how to access ADO.NET data providers and other details specific to certain RDBMS or SQL dialects.

Loading a .daConfig

If you look at the code of the main form of a standard Data Abstract server, you will see the following line of code in the form's Load event:

RemObjects.DataAbstract.Server.Configuration.Load();

This standard, parameterless version of Load will look in three different places to find a .daConfig file:

  • as a DataAbstract.daConfig file next to your application's executable
  • as a DataAbstract.daConfig resource in your application's executable
  • as a resource in RemObjects.DataAbstract.Server.dll

As you can see, if your application does not provide a custom DataAbstract.daConfig, either as a file or as embedded resource, the standard configuration will be used from inside the Data Abstract dll. This is the default for new projects created using the New Project Templates, but you can easily add a custom .daConfig file to your project using the "New Item Templates" dialog.

Manually loading a specific .daConfig

The Configuration class can also load .daConfig from a user-specific location, using the additional Load methods: LoadFromFile, LoadFromResource or LoadFromXml.

Structure

The DataAbstract.daConfig file is divided in two sections: "KnownProviders" and "DatabaseProfiles".

KnownProviders section

This section of the configuration file contains several nodes that identify the name of a Data Abstract driver.

In the following snippet you can see the MSSQL.NET and ODBC.NET nodes:

<Configuration>
  <KnownProviders>
    <MSSQL.NET>
      <AssemblyName Value="System.Data, Version=2.0.0.0...
      <ConnectionClassName Value="System.Data.SqlClient.SqlConnection...
      ...
    </MSSQL.NET>
    <ODBC.NET>
      <AssemblyName Value="System.Data, Version=2.0.0.0...
      <ConnectionClassName Value="System.Data.Odbc.OdbcConnection...
      ...
    </ODBC.NET>
    ...

A Data Abstract driver name is the very first element of a Data Abstract connection string, for example:

MSSQL.NET?Database=Northwind;Server=localhost;User Id=sa;Password=xyz

and the first choice you have to make when using the Schema Modeler Connection Wizard.

All driver definitions must include the following sub nodes:

Node Description
AssemblyName String name of the data provider assembly name to load when using this driver.
ConnectionClassName The name of the class implementing the IDbConnection interface inside the data provider assembly.
DataAdapterClassName The name of the class implementing the IDataAdapter interface inside the data provider assembly.
CommandBuilderClassName The name of the command builder class inside the data provider assembly.
Description A description for this driver.
ParameterHandling This parameter indicates how query parameters are handled (by name or sequentially) and the text identifier required when defining a parameter in a SQL string (i.e. @CustomerName or ?CustomerName).

In addition to this, there's another necessary piece of information: which database profile the driver uses. The possible values for this parameter depend on the next section, DatabaseProfiles.

Some data providers (i.e. those used by the MSSQL.NET or ORACLE.NET drivers) can only refer to one profile as they are RDBMS specific. When dealing with such data providers, you will need to add a node such as:

<Profile Value="MSSQL" />

Others such as ODBC.NET or OLEDB.NET will need to provide a database profile mapping for each of the drivers they support. When dealing with these data providers, you will need a ProfileMappings node like the following:

<ProfileMappings Match="Driver">
  <Driver Name="{Microsoft Access Driver (*.mdb)}" Value="Access" />
  <Driver Name="{SQL Server}" Value="MSSQL" />
  <Driver Name="{Microsoft ODBC Driver for Oracle}" Value="Oracle" />
  <Driver Name="{MySQL ODBC 3.51 Driver}" Value="MySQL" />
  <Driver Name="{Sybase System 10}" Value="Sybase" />
  <Driver Name="{Gemini InterBase ODBC Driver 2.0}" Value="Interbase" />
  <Driver Name="{Firebird/InterBase(r) driver}" Value="Interbase" />
</ProfileMappings>

DatabaseProfiles section

This section of the configuration file contains several nodes that list system queries for a specific RDBMS or SQL dialect details.

The sub nodes of this section name the specific database profile. In the following snippet you can see the MSSQL and Interbase profiles:

<DatabaseProfiles>
  <MSSQL QuotingIdentifiers="[]">
    <GetTableNames SQL="SELECT TABLE_NAME as Name...
    <GetStoredProcedureNames SQL="SELECT SPECIFIC_NAME...
    <GetLastAutoInc SQL="SELECT IsNull(@@Identity, 0)...
    ...
  </MSSQL>
  <Interbase QuotingIdentifiers='""'>
    <GetTableNames SQL="SELECT RDB$RELATION_NAME...
    <GetStoredProcedureNames SQL="SELECT RDB$PROCEDURE_NAME...
    <GetLastAutoInc SQL="SELECT Gen_id({0},0) ...
    ...
  </Interbase>
  ...

All database profiles must contain the following sub nodes:

Node Description
GetTableNames SQL query to execute in order to retrieve the list of tables in a database.
GetStoredProcedureNames SQL query to execute in order to retrieve the list of stored procedures in a database.
GetViewsNames SQL query to execute in order to retrieve the list of views in a database.
GetLastAutoInc SQL query to retrieve the number of the last auto increment number generated by the database or to call a generator.

See Also