User Guide > Map Connectors > Source and Target Map Connectors > SQL Server 2012
Was this helpful?
SQL Server 2012
SQL Server 2012 is a database application that you can connect natively to through an OLE DB interface, or through ODBC. With this connector, the integration platform reads and writes to SQL Server 2012 tables.
The connector uses the SQL Server Native Client 11.0 ODBC driver, which must be installed on your system.
Note:  The Linux platform requires Microsoft Driver version 17.9.1.1.
Note:  The SQL Server 2012, 2016, and 2019 connectors do not read/write data on the Linux platform for CHAR & VARCHAR datatypes when the Microsoft ODBC 17 or 18 Driver is used. This is a known issue of Microsoft Driver: Known issues for the ODBC driver on Linux and macOS - ODBC Driver for SQL Server.
Connectivity Pointers
• In the Server field, enter the name of your server.
• If your database has many tables, selecting the table from a list may take more time than typing the SchemaName.Tablename value in the Source Table/View box. If you enter the table name without the schema name and then connect to the database, you can reselect the table in the source data browser to view it.
• If possible, create query statements using the source database application, so that syntax and validity can be checked by the native application. You can then copy the query statement and paste it in the Query statement field.
• You can use an EZscript to auto-generate a GUID for a variable declared as the uniqueidentifier data type. See Generating a Random Unique Identifier.
Connector Parts
Connector parts are the fields you configure to connect with a data source or target. The fields that are available depend on the connector you select.
For a list of all parts for source connectors, see Specifying Source Connector, Parts, and Properties.
For a list of all parts for target connectors, see Specifying Target Connector, Parts, and Properties.
Property Options
You can specify the following source (S) and target (T) properties:
Property
S/T
Description
AutoCommit
T
If set to True, it allows you to automatically commit changes as they are made by each SQL statement, instead of waiting until the end of the transaction.
Also, if this option is set to True, you cannot roll back changes after they are done. It will overwrite the CommitFrequency value, which means that the changes are committed by each SQL statement irrespective of the value set for CommitFrequency.
The default value is False.
BulkOperations
T
Use bulk operations for faster insert. This property determines if an insert statement is executed for each record or a bulk add is executed for each record. The default is false, the slower setting. If you want to maximize speed and instruct Map Designer to use a bulk add, change this setting to true.
CommitFrequency
T
Allows you to control how often data is committed to the database when the AutoCommit property is set to False.
The default value is zero that is, the data is committed at the end of the transformation, allowing rollback on error. This is the slowest setting. When performing large transformations, this is not practical as it may produce too many transaction log entries.
Specifying a nonzero value indicates that data is committed to the database after inserting or updating specified number of records.
ConstraintDDL
T
Pass-through mechanism that allows you to specify any additional data definition language (DDL) statements that need to be executed when a new table is created. DDL is used to define keys, indexes, constraints and integrity rules for SQL databases. There is no default.
CursorType
S
Type of cursor to use for retrieving records from the source table. Available options are forward only (default), dynamic, and static. See CursorType for details.
Encoding
S/T
The SQL Server 2012 connector is Unicode-based. The encoding property specifies the encoding from which to translate user names and query statements to Unicode before passing them to SQL Server. Default is OEM.
For choices, see Source and Target Map Connectors.
IdentifierQuotes
S/T
All databases have what are called quoted identifiers. You use quoted identifiers to make the SQL statement parseable and distinguish between columns and character data in SQL statements. For example, Oracle uses double quotes for column and table names in SQL statements and uses single quotes for character data. In a SQL statement, you should enclose identifiers containing special characters or match keywords in identifier quote characters (also known as identifiers in SQL-92). For example, the Accounts Receivable identifier is quoted in the following SELECT statement:
SELECT * FROM "Accounts Receivable"
If you do not use identifier quotes, the parser assumes there are two tables, Accounts and Receivable, and returns a syntax error that they are not separated by a comma.
If either of the following values contain a space, set the identifierQuotes property on the source and the target to ““ or Default:
• the value of the source connector part Table/View field.
• the value of a source column name (for example, Account Number).
Otherwise, if the IdentifierQuotes property is set to None, a SQL error is returned and the source table data is not displayed.
IdentifierQuotes has the following options:
• Default
• None
• "
MaxDataLength
S/T
Refers to the maximum data length for long data types. The default is 1 MB. You can reset this number as you choose based on your available memory capabilities and data requirements.
Some ODBC drivers have limitations concerning the maximum data length they can handle. If you choose an application (ODBC) source or target connector and the default setting is not 1MB, Map Designer presets the default in respect of the capabilities of that particular ODBC driver. As a best practice, do not set this property any higher under those conditions.
SystemTables
S/T
If set to true, allows you to see all tables created by the DBA in the database. The system table names appear in the table list. Default is false.
TransactionIsolation
S/T
Allows you to specify an isolation level when reading from or writing to a database table with ODBC. The default is Serializable.
The ANSI SQL 2 standard defines three ways in which serializability of a transaction may be violated: P1 (Dirty Read), P2 (Nonrepeatable Read) and P3 (Phantoms).
The isolation levels are as follows:
• READ_UNCOMMITTED - Permits P1, P2, and P3.
• READ_COMMITTED - Permits P2 and P3. Does not permit P1.
• REPEATABLE_READ - Permits P3. Does not permit P1 and P2.
• SERIALIZABLE - Does not permit any of P1, P2, and P3.
For further details about TransactionIsolation levels, see the Microsoft ODBC SDK documentation.
Views
S/T
If set to True, this property allows you to see the view names in the table list along with the table names. Default is True.
Note:  This property supports only Append and DeleteAndAppend output modes and does not support the Replace output mode.
WhereStmt
S
Provides a pass-through mechanism for SQL connectors where advanced users can construct the Where clause of the SQL query themselves. It can be used as an alternative to writing a lengthy query statement. You may use this to instruct the SQL database server to filter the data based on a particular condition before sending it to the integration platform. There is no default value for this property.
Note:  This property is not applicable when the source connection is a query statement or file. This property enables data filtering when you select a table.
PrimaryKey
T
The PrimaryKey property allows you to specify a list of field names that are used to make the primary key. The field names are delimited by commas. If the PrimaryKey property contains one or more field names, these names are included in the SQL CREATE statement when the connector is in replace mode.
There is one additional requirement for using the PrimaryKey property. The ODBC driver must support integrity enhancement facility (IEF). Only the more advanced ODBC drivers support this.
UseCursors
T
The UseCursors property allows you to turn cursor support on and off. The default is false. If you set the property to true and the specified ODBC driver does not support cursor inserts, Map Designer falls back on the SQL INSERT mode of adding records.
For exports, cursor support is supposed to enhance the performance of inserting records. This appears to be the case for desktop databases such as Access. For database servers, there is no noticeable change in insert speed. They seem to execute prepared queries about as quickly as they handle cursor inserts
Another complication of cursor inserts is that some drivers require that the target table be indexed, otherwise positioned updates (cursors) are not allowed. Two additional properties in the ODBC export connector address this issue: PrimaryKey and ConstraintDDL (see details above).
CursorType
The following CursorType options are available for a SQL Server 2012 connection:
• forward only – A cursor that cannot be scrolled; rows are read in sequence from the first row to the last row only.
This cursor can only move forward through the result set. To return to a previous row, the application must close and reopen the cursor and then read rows from the beginning of the result set until it reaches the required row. Forward-only cursors provide a fast mechanism for making a single pass through a result set. This cursor is less useful for screen-based applications, in which the user scrolls backward and forward through the data. Such applications can use a forward-only cursor by reading the result set once, caching the data locally and performing scrolling themselves. This works well only with small amounts of data.
• static – A cursor that shows the result set exactly as it was at the time the cursor was opened. Sometimes called snapshot cursors.
Static cursors never detect other updates, deletes and inserts made to underlying data while the cursor is open. For example, suppose a static cursor fetches a row and another application then updates that row. If the application re-fetches the row from the static cursor, the values it sees are unchanged, despite the changes made by the other application. All types of scrolling are supported, but providers may or may not support bookmarks.
• dynamic – A cursor that can reflect data modifications made to the underlying data while the cursor is open. Updates, deletes and inserts made by users are reflected in the dynamic cursor. A dynamic cursor can detect any changes made to rows, order and values in the result set after the cursor is opened. Updates made outside the cursor are not visible until they are committed, unless the cursor transaction isolation level is set to "uncommitted".
Choosing a CursorType
Every cursor uses temporary resources to hold its data. These resources can be memory, a disk paging file, temporary disk files, or even temporary storage in the database. The cursor is called a client-side cursor when these resources are located on the client computer and a server-side cursor when these resources are on the server.
Your cursor choice depends on whether you need to change or simply view the data. The following are recommendations from Microsoft:
• If you just need to scroll through a set of results, but not change data, use a forward only (called forward-only in SQL Server) or use the static cursor.
• If you want to synchronize a result set with recent adds, changes, and deletes by all concurrent users, use a dynamic cursor.
Encoding Notes
• Shift-JIS encoding is meaningful only in Japanese operating systems.
• The Encoding property is not the encoding of the database that you connect to, but rather the encoding in which the connector expects to receive SQL query statements to be sent to the database.
Supported Data Types
ID field types are not supported.
Last modified date: 12/03/2024