Oracle Spatial Object Writer Parameters

About Database Connections

Database formats include a Database Connection parameter that defines and stores authentication information. For general information about sharing database connections, please see Using Database Connections. Using Database Connections.

Note that Database Connection parameters differ slightly, depending on context and/or database format.

Connection

From the Connection parameter in a database format, you can do one of the following:

  • Select an existing, previously defined connection. See the section Reusing a Database Connection in Using Database Connections
  • Select Add Database Connection to define a new connection. See database-specific parameters below, as well as the section Adding a Database Connection in a Workspace in Using Database Connections. The new connection can be made visible only to the current user, or can be shared among multiple users.

The name of the Oracle Workspace Manager workspace that will be used by the writer. All tables will be written using the same workspace. If this parameter is omitted, or left blank, the default LIVE workspace will be used.

Persistent Connection

If this parameter is checked (default), the Oracle database connection remains open for other requestors. A persistent connection is useful for workspaces that are long-running, or published using FME Flow.

If this parameter is unchecked, the connection to the Oracle database is closed as soon as possible after data processing is complete.

Layer Parameters

Uppercase Column Names

If this parameter is checked, the writer automatically makes the column names uppercase, and disallows characters in the column names that require quoting within Oracle.

This parameter is only applicable when generating a writer.

Minimum and Maximum X and Y

These values apply to the entire layer – features with coordinate values outside this range will not be correctly indexed.

Spatial Column

Traditionally, FME would assign a GEOM name to all geometry columns stored in Oracle databases in all generated workspace. This gives you the option of modifying what the geometry column will be named in tables created by FME.

Oracle Spatial Object directly supports composite surfaces, 3D polygons and rectangles. Writing of 3D surfaces and solids is available only for Oracle 11g and above. If the Oracle Spatial Object writer detects an older version of Oracle Database, surface features will automatically be downgraded to a 2D representation prior to writing.

Minimum and Maximum Z Ordinate

Specifies the minimum and maximum Z values expected in the dataset.

This directs the writer to write measures to the destination table. When this box is checked and the incoming feature does not have any measures, then null values are written. This option applies when writing to existing tables.

Note  If you are updating an existing table, ensure that the metadata table has proper entry of the measures for that table. The writer does not perform checks on existing tables for their measures support. It writes measures based on the Contains Measures parameter. Therefore, if you attempt to write measures to an existing table that originally did not support measures, this may result in datasets that do not pass Oracle’s validity tests.

However, when creating new tables, the writer takes care of everything including writing to the metadata table. The above parameter is ignored when writing to points, multipoints, multiareas and heterogeneous collections, as Oracle does not support measures for these geometries.

Minimum and Maximum M Ordinate

Specifies the minimum and the maximum measure values expected in the dataset.

Create Spatial Index

Indicates whether or not spatial indexes are to be created as part of the data load.

If No is selected, no spatial index creation will be done.

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 a 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 the 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.

Bulk Write Size

This parameter, also known as chunk size, specifies how many features the writer transmits over the network at a time to the database. Features will get cached in memory until this feature count is reached, and then they will be transmitted as a single chunk to the database. Features Per Transaction is normally a multiple of this parameter. Once all chunks in a transaction are received by the database, the transaction is committed.

Note that the bulk write feature count is at the writer level and not the feature type level.

This parameter has a significant impact on performance. When the database server is physically remote, round-trip time for data transmission can cause bottlenecks in data loading. To reduce network round-trip time, increase the value of this parameter.

This parameter is often confused with Features Per Transaction. Each bulk write is a part of exactly one transaction. So, if Bulk Write Size is greater than Features Per Transaction, then it is automatically reset to the value of the latter.

For optimal performance, make Features Per Transaction large (but not excessive), and set Bulk Write Size to the same value.

Features Per Transaction

This parameter specifies how many features are written to the database before they are committed. It is usually a multiple of Bulk Write Size.

Note that the written feature count is at the writer level and not the feature type level.

  • If this parameter is set to a small number: when a transaction fails, only a small number of features (for example, all features in that transaction) get rolled back.
  • If this parameter is set to a large number: when a transaction fails, a large number of features get rolled back.

In terms of performance, it is undesirable to have this parameter set to a small number because the overhead of the numerous commits might be excessive. It is also undesirable to have this parameter set to a large number because the overhead of keeping track of the large transaction on the database server can be significant.

For optimal performance, make Features Per Transaction large (but not excessive), and set Bulk Write Size to the same value.

This parameter allows for the execution of SQL statements before writing to a table. For example, it may be necessary to clean up a table before attempting to write to it. The statements will be executed only when the first feature arrives at the writer.

For detailed information about SQL functions, click the corresponding menu item in the SQL to Run editor helpClosed.

Available menu options depend on the format.

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 block into SQL statements, 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 or writer (depending on where the SQL statement is executed) with an error. If the specified statement is preceded by a hyphen (“-”), such errors are ignored.

This parameter allows for the execution of SQL statements after a set of tables has been written. For example, it may be necessary to clean up a temporary view after creating it.

For detailed information about SQL functions, click the corresponding menu item in the SQL to Run editor helpClosed.

Available menu options depend on the format.

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 block into SQL statements, 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 or writer (depending on where the SQL statement is executed) with an error. If the specified statement is preceded by a hyphen (“-”), such errors are ignored.

Enforce Strict Attribute Conversion

This parameter specifies how the writer proceeds when a problem arises while converting a value from one of a feature’s attributes to an Oracle column value.

Examples of such problems would be the truncation of a string value to fit into the target character column, an error in writing a non-numeric attribute to a numeric column, or an error converting an FME geometry into an SDO_GEOMETRY value.

  • Yes: The conversion errors result in warnings. Features are logged and dropped from the translation.
  • No: The writer will silently write null values or truncated strings when conversion errors occur.
  • Warn: The writer warns and writes null values or truncated strings when conversion errors occur.

If this parameter is set to Yes, feature geometry will be written from an aggregate. This aggregate must contain individual geometries, namely that 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.
  • If the aggregate does not contain a name that matches a spatial column on the table being written, a null value will be written in INSERT mode. Geometry-specific data normally read from feature attributes will be read from geometry traits instead.

When using this feature, the geometry column cannot be specified and the table must already exist.