Powered by Zoomin Software. For more details please contactZoomin

DataDirect Connect for ADO.NET Data Provider Help

Working with the DB2 Entity Framework Data Provider

Working with the DB2 Entity Framework Data Provider

  • Last Updated: April 16, 2026
  • 7 minute read
    • ADO.NET
    • Documentation

You can work with the Entity Framework data provider in the following ways:

  • By tuning behavior with a connection string. See Configuring Connection Strings for more information.
  • By adding the modifying the storage model file of an Entity Data Model. See Adding the Provider Schema Attribute for more information.
  • By modifying the relevant configuration file using a text editor. For example, you can add options to filter which schema objects to return, configure the data provider's interaction with the .config file, and enable the Logging application block. See Modifying the DB2 Configuration File for more information.

Adding the Provider Schema Attribute

Provider is an attribute of the Schema element in the storage model file of an Entity Data Model (EDM). The storage model file is written in the store schema definition language (SSDL).

The Entity Data Model wizard assigns the value when you select the DB2 data provider. If you are manually defining an Entity Data Model, assign the string DDTek.DB2 to the Provider attribute of the Schema element, as shown in the following example for DB2 for i5/OS V6R1:

<Schema Namespace="AdventureWorksModel.Store" Alias="Self" Provider="DDTek.DB2" ProviderManifestToken="DB2iSeries" xmlns:store="https://schemas.microsoft.com/ado/2007/12/edm/EntityStoreSchemaGenerator" xmlns="https://schemas.microsoft.com/ado/2006/04/edm/ssdl">

Modifying the DB2 Configuration File

The Entity Framework data provider defines a number of configuration options that enable you to customize the behavior of the data provider to meet your functional or performance requirements. You can define configuration options are defined in configuration files. The following table summarizes the characteristics of configuration files in which you can set options.

Configuration File Characteristics

Options Applications Affected  
Machine.config Can affect the model design and application runtime behavior of all the applications running on the machine.
The product Installer specifies many of the default configuration values in this file.
 
devenv.exe.config Can affect how Visual Studio wizards create or update Entity Framework models.  
EdmGen.exe.config Can affect how the command-line EDM Generator tool works with Entity Framework model and mapping files.  
App.config
Web.config
Can affect the runtime behavior of your application.  

The following table provides the typical location of each configuration file.

Location of Configuration Files

Configuration File Location
Machine.config Various locations under the %SystemRoot% directory. For example,
  • \Microsoft.NET\Framework\v2.0.50727\Config
  • \Microsoft.NET\Framework64\v2.0.50727\Config
  • \Microsoft.NET\Framework\v4.0.30319\Config
  • \Microsoft.NET\Framework64\v4.0.30319\Config
The location that is used depends on the Framework version and platform targeted by your application
devenv.exe.config C:\Program Files (x86)\Microsoft Visual Studio 15.0\Common7\IDE
EdmGen.exe.config Various locations under the %SystemRoot% directory. For example:
  • \Microsoft.NET\Framework\v3.5
  • \Microsoft.NET\Framework\v4.0.30319
App.config
Web.config
In your Visual Studio project
Refer to the DataDirect Connect Series for ADO.NET Distribution Guide for information about deployed applications.

The following code fragment shows the syntax and default values of the configuration file:

<ddtek.db2.entity edmSchemaRestrictions="AccessibleExcludingList" enableLoggingApplicationBlock="false">
<storeEdmMappings>
<add storeTypeName="binary" minimumLength="16" maximumLength="16" 	   	primitiveTypeKind="Guid" isDefaultStoreMapping="True" />
 </storeEdmMappings>
 </ddtek.db2.entity>

The following table lists the mapping of the configuration file options to their default values.

Options for the DB2 Configuration File

Option Default Value
defaultSchemaName Empty string
edmSchemaRestrictions AccessibleExcludingList
enableLoggingApplicationBlock False)
labAssemblyName Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL
labLogEntryTypeName Microsoft.Practices.EnterpriseLibrary.Logging.LogEntry
labLoggerTypeName Microsoft.Practices.EnterpriseLibrary.Logging.Logger
storeEdmMappings Various, depending on the data type. See Mapping Data Types and Functions
workarounds 0
maxIdentifierLength 0

Configuration Options

The following configuration option descriptions are listed alphabetically.

defaultSchemaName

Type

Attribute

Description

Specifies the default schema name. The setting affects the whole application.

The defaultSchemaName setting can affect the usefulness of DropCreateDatabaseIfModelChanges. The Entity Framework stores metadata about a model in the database. Setting DefaultSchemaName to an empty string causes the model metadata to be created in the current schema resulting in a model-per-schema approach. Setting DefaultSchemaName to anything else can create the model metadata in the specified schema, which would result in an all-models-for-schema approach, which can be problematic.

Valid Values

Schema | Empty string

When set to an empty string, unqualified tables remain unqualified. An application that uses more than one model must use the empty string value.

When set to Schema, unqualified tables are qualified with Schema. The model metadata is created in the specified schema.

Default

Empty string

edmSchemaRestrictions

Description

Restricts or expands the database objects available to you when you generate a model from a database. The option filters the schema objects that are returned when building the EDM that your application includes. Restricting the objects can also improve performance.

You can add or install the EdmSchemaRestrictions option entry in the app.config or web.config file.

Building large models with the Entity Data Model (EDM) can be very inefficient. For optimal results, consider breaking up a model when it has reached 50 to 100 entities. In addition, carefully consider which objects are actually required in the model.

Valid Values

User | Accessible | AccessibleExcludingList

When set to User, the data provider limits the objects available for the model to those for which the current user is the owner.

When set to Accessible, the model is built against a larger subset.

When set to AccessibleExcludingList, all the schema objects for which the current user has access are returned, less a predefined list of system-related schema.

Default

User

enableLoggingApplicationBlock

Type

Attribute

Description

Enables the Logging Application Block. Refer to the DataDirect Connect Series for ADO.NET Reference for information about using Logging Application Blocks.

Valid Values

True | False

When set to True, the Logging Application Block is enabled.

Default

False

labAssemblyName

Type

Attribute

Description

Specifies the version of the Enterprise Library Logging Application Block(LAB). By default, Entity Framework data providers use the Microsoft Enterprise Library 6.0 Logging Application Block.

NOTE: If you are using any version of the LAB other than the Microsoft Enterprise Library 6.0 binary release or a customized version, you must use the labAssemblyName.

Valid Values

string

where string is the name of the Enterprise Library Logging Application Block that you want to use.

Default

The Enterprise Library 6.0 Logging Application Block:

Microsoft.Practices.EnterpriseLibrary.Logging, Version=6.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL

labLogEntryTypeName

Type

Attribute

Description

Specifies the LogEntry type name for the LogEntry object.

Valid Values

string

Where string is the LogEntry type name.

Default

Microsoft.Practices.EnterpriseLibrary.Logging.LogEntry

labLoggerTypeName

Type

Attribute

Description

Specifies the Logger type name for the Logging Application Block.

Valid Values

string

Where string is the Logger type name.

Default

Microsoft.Practices.EnterpriseLibrary.Logging.Logger

maxIdentifierLength

Type

Attribute

Description

Enables developers to specify the maximum length for all Identifiers. For example, if the developer specifies the length as 129, only those identifiers that are longer than the value specified by the developer are truncated to 129, replacing the end of the identifier with an integer hash-code.

Valid Values

Integer

Where Integer is the Maximum Identifier Length.

Default

30

storeEdmMappings

Type

Element

Description

Enables developers to override the default store-to-primitive type mappings. See Mapping Order in the storeEdmMappings Element Collection for more information.

Valid Values

The storeEdmMappings element can define multiple properties:

storeTypeName. Required. Specifies the store type for which the mapping applies. Valid values are any valid Oracle type name. See also Mapping Data Types and Functions.

primitiveTypeKind. Required. Specifies the PrimitiveTypeKind for which this mapping applies. Valid values are any value from the PrimitiveTypeKind enum.

minimumLength. Specifies the smallest length for which this mapping applies. Valid values are 0 to Int32.MaxValue.

maximumLength. Specifies the largest length for which this mapping applies. Valid values are 0 to Int32.MaxValue.

minimumLength. Specifies the smallest length for which this mapping applies. Valid values are 0 to Int32.MaxValue.

minimumPrecision. Specifies the smallest precision for which this mapping applies. Valid values are 0 to 255.

maximumPrecision. Specifies the largest precision for which this mapping applies. Valid values are 0 to 255.

minimumScale. Specifies the smallest scale for which this mapping applies. Valid values are 0 to 255.

maximumScale. Specifies the largest scale for which this mapping applies. Valid values are 0 to 255.

trueValue. Specifies what constitutes a true value for Boolean mappings. Valid values are any string or integer value.

falseValue. Specifies what constitutes a false value for Boolean mappings. Valid values are any string or integer value.

isDefaultStoreMapping. Specifies whether this mapping must be considered the preferred mapping for the storeType when no specific mapping for the storeType can be found. Valid values are True or False.

workarounds

Type

Attribute

Description

Specifies the non-standard configuration options (workarounds) for data providers which enables you to take full advantage of non-standard or extended behavior in the data providers.

Valid Values

0 | 4 | n

where n is the sum of a combination of workarounds.

When set to 0, no workarounds are used.

When set to 4, the data provider maps byte array to Varbinary for Code First and Model First.

When set to n, multiple workarounds are enabled. Add the string WorkArounds= with a value of n (WorkArounds=n ), where the value n is the cumulative value of all options added together.

Default

0

Mapping Order in the storeEdmMappings Element Collection

The order of the storeEdmMappings element collection determines the preferred mapping for the primitive type when mapping a store type to a primitive type. Consider the following example, where the same store type, smallint, maps to two different primitive types, SByte and Byte.

<ddtek.db2.entity>
<storeEdmMappings>
<add storeTypeName="smallint" minimumLength="1" maximumLength="5"
primitiveTypeKind="Byte"/>
<add storeTypeName="smallint" minimumLength="1" maximumLength="5"
primitiveTypeKind="SByte" />
</storeEdmMappings>
</ddtek.db2.entity>

Since multiple, identical store types exist, the provider chooses the primitive type based on the order specified. In this case, Byte is preferred, since it was is listed before SByte. The pseudo type is smallint_as_byte.

Conversely, the order of the storeEdmMappings element collection determines the preferred mapping for the store type when mapping a primitive type to a store type. Consider the following example where the same primitive type, Byte, maps to two different store types, CHAR(8) and VARCHAR(8).

<Ddtek.db2.entity>
<storeEdmMappings>
<add storeTypeName="char" primitiveTypeKind="Boolean" minimumLength="1" maximumLength="1" />
<add storeTypeName="varchar" primitiveTypeKind="Boolean" minimumLength="2" maximumLength="3" />
</storeEdmMappings>
</ddtek.db2.entity>

Since multiple, identical primitive types exist, the provider chooses the store type based on the order specified. In this case, CHAR(1) is preferred, since it was is listed before VARCHAR(3). The pseudo type is char_as_boolean.

TitleResults for “How to create a CRG?”Also Available inAlert