Writer Directives – All Geodatabase Types

This section describes the directives that the Geodatabase writer module recognizes.

Each directive is prefixed by the current <WriterKeyword>_ when it is placed in a mapping file. By default, the <WriterKeyword> for the Geodatabase writer is the same as the <WriterType>.

IGNORE_FAILED_FEATURE_ENTRY

Required/Optional: Optional

This directive tells the Geodatabase writer whether or not it should ignore features that would normally cause the translation to fail. It allows you to ignore features that are topologically incorrect, are not supported by the Geodatabase writer, or conflict with the definition of the table to which it is to be inserted (that is, they are outside of the geometry envelope specified by the feature class). Additionally, polygons, donuts, or aggregates of polygons/donuts that cannot be reoriented will be ignored.

If the GEODATABASE_<SDE|MDB|FILE>_IGNORE_FAILED_FEATURE_ENTRY statement is not specified or given the value NO, then features are not ignored and will cause the translation to fail when encountered. Additionally, the three other associated directives described below will now be put into effect.

Parameter: <ignore_failed_features>

Values: YES | NO

Default Value: NO

Workbench Parameter: Ignore Failed Features

Example:

GEODATABASE_SDE_IGNORE_FAILED_FEATURE_ENTRY YES

MAX_NUMBER_FAILED_FEATURES

Required/Optional: Optional

This directive informs the Geodatabase writer of the number of features to ignore before causing a translation to fail due to a problematic feature. (However, the translation may still fail for other reasons.)

This directive is only applicable if IGNORE_FAILED_FEATURE_ENTRY is set to YES.

Parameter: <max_number_failed_features>

Values: To ignore all failed features: -1; otherwise 0 or a positive integer.

Workbench Parameter: Max Number of Features to Ignore

Example:

GEODATABASE_SDE_MAX_NUMBER_FAILED_FEATURES 100

DUMP_FAILED_FEATURES

Required/Optional: Optional

This directive gives the user the option of storing the failed features to an FFS file so that they can be viewed at a later time. For this statement to be used, GEODATABASE_<SDE|MDB|FILE>_IGNORE_FAILED_FEATURE_ENTRY must be specified and have the value YES.

Parameter: <dump_failed_features>

Values: YES | NO

Workbench Parameter: Dump Failed Features to File

Default: NO

FFS_DUMP_FILE

Required/Optional: Optional

This directive allows you to choose where the file containing failed features should be stored. The failed features will be stored in the FME Feature Store format. The file will be created automatically, but will only get created if there is a failed feature. If this directive is specified and a failed feature is encountered, then if a file with the same name as given to this directive already exists, it will be overwritten. This directive must be specified if

GEODATABASE_<SDE|MDB|FILE>_DUMP_FAILED_FEATURES

is specified and has the value YES.

Parameter: <ffs_dump_file>

Values: path and filename

If either the path or the filename contains a space, the value must be enclosed in double quotation marks. The filename must end in the extension .ffs.

Workbench Parameter: Failed Feature Dump Filename

Example:

GEODATABASE_MDB_FFS_DUMP_FILE "c:\user temp\bad features.ffs"

BEGIN_SQL{n}

Sometimes, you must execute some SQL statements prior to opening a table. For example, it may be necessary to ensure that a view exists before 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 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.

Required/Optional

Optional

Workbench Parameter

Begin SQL

END_SQL{n}

Sometimes you must execute some SQL statements after a set of tables has been read. For example, it may be necessary to clean up a temporary view after creating it in BEGIN_SQL.

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

Required/Optional

Optional

Workbench Parameter

End SQL