Microsoft SQL Server and Azure SQL Database Non-Spatial Writer Parameters
Database Connection
Connections store authentication information. For general information about sharing database connections, please see Using Database Connections.
Note that different subsets of the Database Connection parameters below are made available in different contexts.
This parameter specifies a database connection for the reader through a drop-down menu. The Add Database Connection option in the menu allows you to create a new connection. The connection requires a name that describes the connection.
Note: The following characters are not allowed in connection names: ^ \ / : * ? " < > | & = ' + % #
The new connection can be made visible only to the current user, or can be shared among multiple users.
Connection Parameters
The host name of the Microsoft SQL Server or Azure SQL Database. (It is not necessary to specify a port if a default configuration is used.)
If you have configured your Microsoft SQL Server database to use a non-standard port number, you can specify this port here.
The correct syntax is:
<HostName>,<port>
or
<IP>,<port>
The name of the database to connect to.
When connecting through a Windows user account, select Windows Authentication. The database can validate the account name and password using the Windows principal token in the operating system.
The user account is retrieved by Windows, so if you choose Windows Authentication, the Username and Password parameters are ignored.
Select SQL Server Authentication to proceed with specifying login credentials through the Username and Password parameters.
When Authentication is set to SQL Server Authentication, enter the username and password to access the database.
Note: Note: This parameter is not present in the Azure SQL Database reader and writer. The Azure SQL Database reader and writer will always request Secure Sockets Layer (SSL) encrypted connections.
When selected, this parameter requests Secure Sockets Layer (SSL) encryption for the connection. If the server does not have a certificate trusted by the client machine, the connection will fail. Otherwise, data will be encrypted before traveling over the network. There are multiple ways to trust a server certificate on a client machine.
If this parameter is not selected, encryption behavior will be determined by encryption properties set for SQL Server Native Client, and for SQL Server.
Note: Tip: When Encrypt Connection is selected, please provide a fully qualified Server name. For example, a server named safe-sql-server might have a fully qualified name of safe-sql-server.dev.safe. This fully qualified name should be an exact match for the server name on the trusted certificate.
Additional Format Parameters (Workbench Navigator)
Some parameters are accessible only from the Workbench Navigator after you add a reader or writer to a workspace (that is, they are not visible in the reader or writer parameters dialog).
When set to Yes, this parameter changes the insert mode from feature-by-feature to batch. This can result in anywhere from six to ten times greater insertion speed. The compromise is reduced granularity in errors, with one invalid feature potentially causing the failure of a complete transaction.
Note: The speed of the bulk insert will increase with transaction size (fewer transactions = faster insert). Larger transaction sizes also mean that if a transaction fails, there will be more rows to re-insert.
In Microsoft Azure SQL Database Non-Spatial (MSSQL_AZURE), Bulk Insert is very important, as the insertion speed increase is on the order of 300x. However, for Bulk mode to work with Azure, the Server and Username parameters must be changed:
- Server: tcp:SERVERNAME.database.windows.net
- Username: USERNAME@SERVERNAME
The remaining parameters can be left unchanged.
Note: Bulk Insert (which is set to Yes by default) invalidates foreign key constraints in order to improve loading speed. You can set this parameter to No in the Navigator, or repair foreign key constraints after writing.
This parameter specifies the transaction number of the last successful transaction. When loading data for the first time, set this value to 0.
This parameter tells the writer when to start actually writing features into the database. The writer does not write any features until the incoming feature belongs to a transaction whose transaction number is one past the specified transaction number.
Specifying a value of 0 (which is the usual setting) causes every feature to be output. A non-zero value is only specified when a data load operation is being resumed after failing partway through.
This parameter is useful for resuming writing after a transaction fails. The log will print a message similar to this:
Translation aborted – rerun by setting the writer parameter “Transaction to Start Writing At” to n
where n is the transaction number. Transaction numbers are an integer sequence (0, 1, 2, 3, etc.). All features written in the transaction whose number is logged will have been rolled back.
At this point, you might discover an Oracle server access issue or an issue in the input features, such as features that violate the primary key constraint of the destination table. If you can resolve the issue without changing the ordering of input features (for example, restore access to Oracle server, or regenerate the primary key attribute values on the features), you can then rerun translation by following the instruction in the log message.
During the rerun, all features in transactions prior to the transaction whose number is logged are processed by the translation, enter into the writer, and then become ignored. Features belonging to transactions whose number is equal to or greater than the transaction number logged will be written to the destination table.
Note: If this parameter is set to 0, then all features are written.
This parameter sets the number of features to be placed in each transaction before a transaction is committed to the database.
A default value of 500 is used as the transaction interval.
If this parameter is set to 0, then feature-based transactions are used. As each feature is processed by the writer, it is checked for an attribute called fme_db_transaction. The value of this attribute specifies whether the writer should commit or roll back the current transaction.
The value of the attribute can be one of COMMIT_BEFORE, COMMIT_AFTER, ROLLBACK_AFTER or IGNORE. If the fme_db_transaction attribute is not set in any features, then the entire write operation occurs in a single transaction.
The time, in seconds, after which to terminate a query to the database if it has not yet returned a result.
If set to 0, there is no timeout. The default is 30.
Note: If this value is not set high enough, then the query will return the error Provider Error - Timeout Expired.
This parameter allows you to execute ad-hoc SQL before opening a table. For example, it may be necessary to ensure that a view exists prior to attempting to read from it.
Upon opening a connection to read from a database, the reader looks for the directive <ReaderKeyword>_BEGIN_SQL{n} (for n=0,1,2,...), and executes each such directive’s value as an SQL statement on the database connection.
Multiple SQL commands can be delimited by a character specified using the FME_SQL_DELIMITER directive, embedded at the beginning of the SQL block. The single character following this directive will be used to split the SQL, which will then be sent to the database for execution.
Note: Include a space before the character.
For example:
FME_SQL_DELIMITER ; DELETE FROM instructors; DELETE FROM people WHERE LastName='Doe' AND FirstName='John'
Multiple delimiters are not allowed and the delimiter character will be stripped before being sent to the database.
Any errors occurring during the execution of these SQL statements will normally terminate the reader with an error. If the specified statement is preceded by a hyphen (“-”), such errors are ignored.
This parameter allows you to execute ad-hoc SQL after closing a set of tables. For example, it may be necessary to clean up a temporary view after writing to the database.
Just before closing a connection on a database, the reader looks for the directive <ReaderKeyword>_END_SQL{n} (for n=0,1,2,...), and executes each such directive’s value as an SQL statement on the database connection.
Multiple SQL commands can be delimited by a character specified using the FME_SQL_DELIMITER directive, embedded at the beginning of the SQL block. The single character following this directive will be used to split the SQL, which will then be sent to the database for execution. Note: Include a space before the character.
For example:
FME_SQL_DELIMITER ; DELETE FROM instructors; DELETE FROM people WHERE LastName='Doe' AND FirstName='John'
Multiple delimiters are not allowed and the delimiter character will be stripped before being sent to the database.
Any errors occurring during the execution of these SQL statements will normally terminate the reader with an error. If the specified statement is preceded by a hyphen (“-”), such errors are ignored.