Jaa

OLE DB Source

  • Artikkeli

The OLE DB source extracts data from a variety of OLE DB-compliant relational databases by using a database table, a view, or an SQL command. For example, the OLE DB source can extract data from tables in Microsoft Access or SQL Server databases.

Note

To load data from a data source that uses Microsoft Office Excel 2007, use an OLE DB source. You cannot use an Excel source to load data from an Excel 2007 data source. For more information, see OLE DB Connection Manager. To load data from a data source that uses Microsoft Office Excel 2003 or earlier, use an Excel source. For more information, see Excel Source.

The OLE DB source provides four different data access modes for extracting data:

  • A table or view.
  • A table or view specified in a variable.
  • The results of an SQL statement. The query can be a parameterized query.
  • The results of an SQL statement stored in a variable.

If you use a parameterized query, you can map variables to parameters to specify the values for individual parameters in the SQL statements.

This source uses an OLE DB connection manager to connect to a data source, and the connection manager specifies the OLE DB provider to use. For more information, see OLE DB Connection Manager.

A Integration Services project also provides the data source object from which you can create an OLE DB connection manager, making data sources and data source views available to the OLE DB source. For more information, see Data Source (SSIS) and Data Source View (SSIS).

Depending on the OLE DB provider, some limitations apply to the OLE DB source:

  • The Microsoft OLE DB provider for Oracle does not support the Oracle data types BLOB, CLOB, NCLOB, BFILE, OR UROWID, and the OLE DB source cannot extract data from tables that contain columns with these data types.
  • The IBM OLE DB DB2 provider and Microsoft OLE DB DB2 provider do not support using an SQL command that calls a stored procedure. When this kind of command is used, the OLE DB source cannot create the column metadata and, as a result, the data flow components that follow the OLE DB source in the data flow have no column data available and the execution of the data flow fails.

The OLE DB source has one regular output and one error output.

Using Parameterized SQL Statements

The OLE DB source can use an SQL statement to extract data. The statement can be a SELECT or an EXEC statement.

The OLE DB source uses an OLE DB connection manager to connect to the data source from which it extracts data. Depending on the provider that the OLE DB connection manager uses and the Relational Database Management System (RDBMS) that the connection manager connects to, different rules apply to the naming and listing of parameters. If the parameter names are returned from the RDBMS, you can use parameter names to map parameters in a parameter list to parameters in an SQL statement; otherwise, the parameters are mapped to the parameter in the SQL statement by their ordinal position in the parameter list. The types of parameter names that are supported vary by provider. For example, some providers require that you use the variable or column names, whereas some providers require that you use symbolic names such as 0 or Param0. You should see the provider-specific documentation for information about the parameter names to use in SQL statements.

When you use an OLE DB connection manager, you cannot use parameterized subqueries, because the OLE DB source cannot derive parameter information through the OLE DB provider. However, you can use an expression to concatenate the parameter values into the query string and to set the SqlCommand property of the source.

In SSIS Designer, you configure an OLE DB source by using the OLE DB Source Editor dialog box and map the parameters to variables in the Set Query Parameter dialog box.

Specifying Parameters by Using Ordinal Positions

If no parameter names are returned, the order in which the parameters are listed in the Parameters list in the Set Query Parameter dialog box governs which parameter marker they are mapped to at run time. The first parameter in the list maps to the first ? in the SQL statement, the second to the second ?, and so on.

The following SQL statement selects rows from the Product table in the AdventureWorks database. The first parameter in the Mappings list maps to the first parameter to the Color column, the second parameter to the Size column.

SELECT * FROM Production.Product WHERE Color = ? AND Size = ?

The parameter names have no effect. For example, if a parameter is named the same as the column to which it applies, but not put in the correct ordinal position in the Parameters list, the parameter mapping that occurs at run time will use the ordinal position of the parameter, not the parameter name.

The EXEC command typically requires that you use the names of the variables that provide parameter values in the procedure as parameter names.

Specifying Parameters by Using Names

If the actual parameter names are returned from the RDBMS, the parameters used by a SELECT and EXEC statement are mapped by name. The parameter names must match the names that the stored procedure, run by the SELECT statement or the EXEC statement, expects.

The following SQL statement runs the uspGetWhereUsedProductID stored procedure, available in the AdventureWorks database.

EXEC uspGetWhereUsedProductID ?, ?

The stored procedure expects the variables, @StartProductID and @CheckDate, to provide parameter values. The order in which the parameters appear in the Mappings list is irrelevant. The only requirement is that the parameter names match the variable names in the stored procedure, including the @ sign. The order in which the parameters appear in the Mappings list is irrelevant.

Mapping Parameters to Variables

The parameters are mapped to variables that provide the parameter values at run time. The variables are typically user-defined variables, although you can also use the system variables that Integration Services provides. If you use user-defined variables, make sure that you set the data type to a type that is compatible with the data type of the column that the mapped parameter references. For more information, see Integration Services Variables.

Troubleshooting the OLE DB Source

Starting in Microsoft SQL Server 2005 Service Pack 2 (SP2), you are able to log the calls that the OLE DB source makes to external data providers. You can use this new logging capability to troubleshoot the loading of data from external data sources that the OLE DB source performs. To log the calls that the OLE DB source makes to an external data provider, enable package logging and select the Diagnostic event at the package level. For more information, see Troubleshooting Package Execution.

Configuring the OLE DB Source

You can set properties programmatically or through SSIS Designer.

For more information about the properties that you can set in the OLE DB Source Editor dialog box, click one of the following topics:

The Advanced Editor dialog box reflects the properties that can be set programmatically. For more information about the properties that you can set in the Advanced Editor dialog box or programmatically, click one of the following topics:

For more information about how to set the properties, click one of the following topics:

See Also

Concepts

OLE DB Destination
Integration Services Variables
Creating Package Data Flow

Other Resources

Integration Services Sources

Help and Information

Getting SQL Server 2005 Assistance

Change History

Release History

15 September 2007
New content:
  • Explained how an OLE DB connection manager cannot use parameterized subqueries.

12 December 2006
New content:
  • Added a note about the use of Excel 2007 data sources.
  • Added information about how SQL Server 2005 SP2 includes new logging messages that enable users to troubleshoot the calls that the source makes to external data providers.

5 December 2005
New content:
  • Added information about using parameterized SQL statements.