Microsoft SQL Server and Azure SQL Database Spatial Writer 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:

<Host>[\<Instance>][,<port>]

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.

Specifies whether to write geometry (planar data) or geography (geodetic data) when writing to tables.

This parameter works only in combination with the Spatial Column parameter.

Specifies the geometry or geography column to use when writing to tables.

This parameter works only in combination with the Spatial Type parameter.

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.

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.

When writing geography (geodetic) data, polygons must be oriented according to the left-hand rule: outer boundaries must be counter-clockwise and inner boundaries must be clockwise.

The default for this parameter is Yes. If this parameter is set to No, FME will not automatically reorient polygons. You may want to set this parameter to No if your input polygons are known to have correct orientation.

Note: FME determines polygon orientation by projecting features onto a plane that does not wrap around the earth’s poles or 180-degree meridian, and does not take into account the curvature of the earth. Therefore, in some cases, FME may incorrectly (re)orient polygons.

If this parameter is set to Yes, feature geometry will be written from an aggregate. The default is No.

This aggregate must contain individual geometries (each part is independent from the others and is its own complete geometry). Each part geometry of the aggregate must have a name.

If the aggregate contains geometries with names that match the spatial columns of the table being written, the geometries will be written to the appropriate columns.

When using this feature, the geometry/geography columns cannot be specified.