Esri Mobile Geodatabase Writer Parameters

Note   The values populated in this parameter dialog set the values for writer parameters and for feature type parameters. Since some feature type parameters have equivalent writer-level parameters, the parameter box value will be used in two places. Feature type parameters take precedence over writer parameters. The only time the writer-level parameters will be used is when there is no equivalent feature type parameter, or if the parameter was not supplied.

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.
Note about SQL View Editing: The SQLExecutor transformer supports File Geodatabase, Mobile Geodatabase, and ArcSDE Geodatabase formats. However, the SQL queries it is capable of performing are limited. If running the SQL fails, FME will try to recognize the SQL as a view statement of one of the following forms:
CREATE VIEW viewname AS querydescription;
CREATE OR REPLACE viewname AS querydescription;
DROP VIEW viewname;
If any of these case-insensitive queries is identified, the geodatabase will call custom view calls to delete or create views as requested.

Database Connection

Mobile Geodatabase Path

Select a mobile geodatabase file.

  • When unchecked (default) and a database already exists, then tables and features are written to the existing database.
  • When checked, any existing database is deleted before writing begins. Checking this option also enables the Template File parameter.
Warning  After a database is deleted, it cannot be recovered – all data is lost.

If a database does not exist when writing begins, a new database is created.

If a Template Mobile Geodatabase is specified, the writer will make a copy of the template into the location specified in the Writer Dataset parameter. All operations will be performed on the copy while the original Mobile Geodatabase remains unchanged.

The parameter is available only when Overwrite Existing Database is enabled.

Note  Since it is doing a complete copy, any data present in the template will also be copied to the destination. To remove unwanted data from tables or feature classes, set Truncate Table to Yes on each feature type. Alternatively, to copy only schema and not data, use ArcGIS to export the schema to an XML Workspace Document, then set the writer to import the resultant schema with the Import XML Workspace Document (Schema Only) parameter (below).

This option specifies what to import from the Esri XML Workspace Document into the destination Geodatabase:

  • Schema Only – Import the schema without any data from the feature classes and tables.
  • Data and Schema – Import both the schema and the data from the feature classes and tables.

The import occurs after opening the Geodatabase for writing, but before any tables are created or features are written. Any error that occurs during import will cause the translation to fail.

Indicates which transaction mechanism the Geodatabase writer should use. Within ArcGIS, there are currently two transaction mechanisms: edit sessions and (regular) transactions.

An edit session corresponds to a long transaction. During an edit session, edits made by other users do not become visible until the edit session is ended. If a translation does not complete successfully and the Geodatabase writer is using an edit session, then all the edits will be discarded.

  • Edit Session: Starts an edit session and then ends it when the translation is finished. This value should be used when edits are made to the tables that have custom behavior associated with them.
  • Transactions: Starts the (regular) transaction mechanism. This can be used only when writing to non-versioned tables that do not have custom behavior.
  • None: No transaction mechanism is used. This can be used only when writing to non-versioned tables that do not have custom behavior.

This setting defines the writer behavior when a Feature Dataset is provided. There are three options:

  • Write Feature Dataset (default) – If a Feature Dataset is specified, it will write it if possible.
  • Warn and Ignore Feature Dataset – In this mode, if a Feature Dataset is specified, a warning will be logged and the writer will treat it as if the Feature Dataset was not provided.
  • Error and End Translation – In this mode, if a Feature Dataset is specified, an error will be logged and the translation will end.

Geometry Settings

ArcGIS geometry has to satisfy certain constraints to be considered valid. For example, polygons must have more than 2 vertices. This parameter allows you to specify whether geometry that breaks those constraints will be simplified to ensure only valid geometry is written.

Note that simplifying geometries can be resource-intensive.

For details on the conditions for invalid geometry and how it is simplified, please refer to ArcGIS documentation: Simplifying a Geometry and Calling the Simplify Method.

Determines whether or not the dataset contains z coordinates. Valid values are Yes, No, or Auto Detect. The default is Auto Detect.

Because Geodatabase does not allow mixed 2D and 3D features in the same feature class, it is best to choose a value of Yes for this parameter if you have mixed dimensions. The 2D features will be forced to 3D.

When set to Auto Detect, the writer determines the dimension of the feature class by checking the dimension of the first feature headed for that feature class.

Advanced

This parameter determines what version of Geodatabase should be created: 9.3, 10.0, or Current (which is the default).

The value to use for the Z coordinate(s) when writing a 2D feature to a 3D feature class.

If this parameter is not specified, a default value of 0 is used.

Transactions do not get used unless the Transaction Type parameter is set to Transactions. This parameter instructs the Geodatabase writer when to begin to write features to the Geodatabase.

The writer does not write any features to the Geodatabase until a feature is reached that belongs to <last successful transaction> + 1. Specifying a value of 0 causes the Geodatabase writer to use transactions and to write every feature to the Geodatabase. Usually, the value specified is 0 – a positive non-zero value is only specified when a data load operation is being rerun.

If this parameter is not specified and transactions are being used (that is, the Transaction Type parameter is set to Transactions), then a default value of 0 is used.

The number of features that FME places in each transaction before a transaction is committed to the database.

Default: 1000

When Transaction Type is set to Edit Session, this value is used to determine how many features to place in each edit operation within the edit session.

Note  The current transaction is committed and a new transaction is started whenever a new table is created or opened, even if the transaction interval was not reached.

This parameter tells the writer whether it should ignore features that would usually cause the translation to fail. This includes features that are topologically incorrect, are not supported by the 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, the writer will also ignore polygons, donuts, or aggregates of polygons/donuts that cannot be reoriented.

The default setting is No, which means that failed features are not ignored and will cause the translation to fail when encountered.

This parameter sets 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.)

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

This parameter allows you to store the failed features to an FFS file for later viewing.

This parameter allows you to specify an FME Feature Store (FFS) file to store any failed features.

This file will be created automatically, but will only be created if there is a failed feature.

Note  If the writer encounters a failed feature and writes to this file, and if a file with the same name already exists, the existing file will be overwritten.

This parameter is required when Dump Failed Features to File is set to Yes.

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.

Specifies which map units should be used when creating a new annotation feature class. Its value will be applied to all annotation feature classes created by the writer identified by the writer keyword.

A Multi-Writer should be used when annotation feature classes with different map units need to be created. This parameter is not used when opening an existing annotation feature class. If the writer creates an annotation feature class, and this parameter is set to Unknown Units (the default value), then the writer tries to determine which type of unit the spatial reference uses and sets Annotation Units to the closest unit that is greater than or equal to it (with respect to its meters per unit value). If a local/unknown coordinate system is used, the units are set to meters.

Determines whether or not the dataset contains measures. The value of this parameter will be overridden by the Feature Type parameter Contains Measures if a value is specified for it.

Default: No

Note  This parameter is used only when creating new feature classes.

Enables fast deletes when feature operation is set to Delete.

  • Yes – Combines WHERE clause predicates up to a limit of 32K characters at a time. If the limit is exceeded, a new query to the table is created.
  • No – Slower deletes by creating a query to the table for each feature.

Enables Load Only mode when feature operation is set to Insert.

Load only mode disables the updating of the spatial index while data is loading on a feature class or table, and then rebuilds the indexes.

Note  On Enterprise Geodatabase, this mode only works if writing to a feature class (not table), and the feature class has no extensions.
  • Yes – Load Only mode used for inserts when possible.
  • No – Load only mode used only when creating a new feature class or table.

Determines whether to perform validation on features being written to the geodatabase.

  • Yes – Validation is performed on the subtype, attribute rules, relationship rules, network connectivity rules and any custom rules present on the feature class. Failed features will be logged with an extended error message describing the reason for the failure.
  • No – Validation is not performed.

Determines whether to perform simplification on network features being written to the geodatabase.

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.

Note  Before writing SQL to run on a geodatabase, please refer to Esri guidelines: What type of data can be edited using sql? (For example, you should avoid dropping feature classes in SQL.)

Indexes

When creating tables, Mobile Geodatabases can have indexes assigned to individual fields. These indexes may have the following properties:

  • Ascending – Values in fields with this index will each be maintained in ascending order.
  • UniqueAscending – Values in fields with this index will each be kept in ascending order and be different from one another.