Registering a DDEX Provider Specialized for ODBC
It is possible to modify an existing ODBC data provider slightly at design time by using code or XML in such a way that its behavior is adapted, or specialized, for your DDEX implementation. In this scenario, the Windows registry provides the means by which specialization files are located.
Registering the Provider
To register your ODBC provider implementation, do the following:
1. Add a Specialization Registry Key
Add a specialization registry key indicating that the OLE DB provider is specialized for your DDEX implementation. This new key must appear under the Specialization key under the DDEX provider for ODBC. The key value is the unqualified name of the DLL that implements the ODBC driver, or, if this is not possible, the name of the driver that would appear as DriverName in the connection string as "DRIVER={DriverName}". Following is an example of the key value as DLL name, provided as a GUID.
HKLM\SOFTWARE\Microsoft\VisualStudio\9.0\DataProviders\{C3D4F4CE-2C48-4381-B4D6-34FA50C51C86}\Specialization\MYODBC32.DLL
2. Specify a Codebase Value, Optionally
If the ODBC provider specialization requires code, you must also specify a Codebase value for this key that identifies the full path to the assembly that implements the code.
3. Specify Specialized Objects
The base implementation of the DDEX provider for ODBC supplies a default implementation for each supported object. It also allows for selective overriding of certain behavior, and in many cases it allows the substitution of support objects. When announcing its capabilities, this DDEX provider attempts to locate and instantiate specialized objects registered for a specific OLE DB provider.
Underneath the key for the ODBC driver DLL, provide names of supported objects with implementation details. Following is a set of possible support objects:
IVsDataConnectionPromptDialog
IVsDataConnectionProperties
IVsDataConnectionUIControl
IVsDataObjectSupport
IVsDataSourceInformation
IVsDataViewSupport
DDEX providers must also include in the registry an indication of which objects they support. They must do this for two reasons:
The DDEX engine, as well as clients, must be able to determine the capabilities of a given provider without needing to load the provider's assembly.
In some cases, it may be necessary for the provider to provide information about how to instantiate or implement one or more of the supported objects.
To indicate which objects are supported, a provider must do the following:
Add keys for additional supported objects. For each of these, provide the name of a managed type that provides the implementation as the Default value of the key. This name is automatically scoped in the assembly specified by the Codebase value, but it can also be a fully qualified type name including assembly details. Following are additional keys you can specify for your additional supported objects:
IVsDataConnectionPromptDialog
IVsDataConnectionProperties
IVsDataConnectionUIControl
IVsDataObjectSupport
IVsDataSourceInformation
IVsDataViewSupport
Note that the IVsDataObjectSupport and IVsDataViewSupport keys provide the location of the respective XML files. (See DDEX Data Object Support and DDEX Data View Support for more information.) These can be specified directly, as a path to a file location on disk, or as a pointer to a resource in a specified assembly. This eliminates needing to implement these classes to manually provide an XML stream.
Note, too, that for the IVsDataSourceInformation key, you can insert various name/value pairs. These can provide information about the static data source directly, without needing to provide code to implement the IVsDataSourceInformation class.
4. Map to a Data Source
The DDEX provider for ODBC supports a 1:1 mapping between a DDEX data source and corresponding OLE DB provider. It is typically the case that an ODBC provider is written for a specific data source.
To map a data source to an ODBC provider, do the following:
If it does not already exist, create the DDEX data source by doing the following:
Create a GUID identifier for the data source and place it in the registry under DataSources.
Add a DefaultProvider value to this key, whose value is the GUID of the default DDEX provider for the data source.
Provide a value on the root specialization key for the OLE DB provider (the one named with the ProgID value). This announces the availability of the OLE DB provider specialization for the specified data source.
Provide a DataSource key whose value is the GUID of the DDEX data source.
Map the DDEX data source to the OLE DB provider by setting the SpecializedProvider registry value (under registration key for the DDEX data source), whose value is set to the ProgID of the corresponding OLE DB provider.