Data Sources and Data Stores

The FDO API uses connection semantics to implement access to feature schema data. The term data store is used to refer to a collection of zero or more objects, which instantiate class definitions belonging to one or more FDO feature schema. The connection is to a data store because that is where data objects are stored. The underlying data source technologies used to hold data stores can be relational databases, such as, a MySQL database, or a file-based solution, such as an SDF file.

The mapping of a data store to data source technology can be one-to-one or many-to-one. For example, it is

• One-to-one when the connection is made by way of the OSGeo FDO Provider for ArcSDE and the ArcSDE server is using an Oracle database.
• Many-to-one when the data source is a MySQL database and the connection is made by way of the OSGeo FDO Provider for MySQL (in this case, the data store is like a container within a container).

When many-to-one mapping is possible, a connection can be made in one or two steps. For more information, see Establishing a Connection and The Essential FDO.

The underlying data source technologies differ in the connection parameters used for connecting to a particular provider. The values for these parameters are generated during the installation and configuration of the container technologies. For more information about these values and the process of installing and configuring the associated data source technologies, see the appropriate appendix in this document and The Essential FDO.

Providers

You connect to a data store by way of a provider.

The FDO API contains a registry interface that you can use to register or deregister a provider. See the class FdoProviderRegistry in Inc/Fdo/ClientServices/ProviderRegistry.h.

The providers are registered during the initialization of the FDO SDK. In order to connect to a provider, you will need the name of the provider in a particular format: <Company/Foundation/Originator>.<Provider>.<Version>. The <Company/Foundation/Originator> and <Provider> values are invariable. For specific values, see The Essential FDO.

In order to connect, you will need the full name including the <Version> value. You can retrieve the full name from the registry and display the set of provider names in a connection menu list. If, for whatever reason, you deregister a provider, save the registry information for that provider in case you want to reregister it again. The provider object returned by the registry has a Set() method to allow you to change values. However, the only value you can safely change is the display name. Sample code for using the provider registry is located in Establishing a Connection.

The registry contains the following information about a provider:

• Name. The unique name of the feature provider. This name should be of the form <Company/Foundation/Originator>.<Provider>.<Version>, for example, Autodesk.Oracle.3.0 or OSGeo.MySQL.3.0.
• DisplayName. A user-friendly display name of the feature provider. The initial values of this property for the pre-registered providers are “Autodesk FDO Provider for Oracle”, “OSGeo FDO Provider for SDF”, etc., or the equivalent in the language of the country where the application is being used.
• Description. A brief description of the feature provider. For example, the the OsGeo FDO Provider for SDF description is “Read/write access to Autodesk's spatial database format, a file-based personal geodatabase that supports multiple features/attributes, spatial indexing, and file-locking.”
• Version. The version of the feature provider. The version number string has the form <VersionMajor>.<VersionMinor>.<BuildMajor>.<BuildMinor>, for example, 3.0.0.0.
• FDOVersion. The version of the feature data objects specification to which the feature provider conforms. The version number string has the form <VersionMajor>.<VersionMinor>.<BuildMajor>.<BuildMinor>, for example, 3.0.1.0.
• libraryPath. The FULL library path including the library name of the provider, for example, <FDO SDK Install Location>/bin/FdoRdbms.dll.
• isManaged. A flag indicating whether the provider is a managed or unmanaged .NET provider.