Microsoft Access Writer Parameters

The password to access the database.

For existing databases, it may be omitted for Access databases without password protection.

If the database does not exist, then the newly created Microsoft Access database will be protected by this password.

Tells the Microsoft Access writer what version of database should be created. If the database file already exists, the writer will automatically detect and use the correct version.

• If this option is unchecked (default) and a database already exists, then tables and features are written to the existing database.
• If this option is checked, any existing database is deleted before writing begins.

If no database exists when writing begins, a new database is created.

Note: After a database is deleted, it cannot be recovered – all data is lost.

If a template file is specified, the destination file is replaced with a copy of the template before writing begins.

The type of SQL operation that should be performed by the writer.

See Writer Mode Specification.

If Yes, the writer will compress the database after all features have been written, using the existing MDB database option to compact.

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.

The number of features to be placed in each transaction before a transaction is committed to the database.

If set to 0, feature-based transactions are used. As each feature is processed by the writer, they are checked for attribute fme_db_transaction. The value of this attribute specifies whether the writer should commit or rollback the current transaction. The value of the attribute can be one of COMMIT_BEFORE, COMMIT_AFTER, ROLLBACK_AFTER or IGNORE.

The default is 500.

If attribute fme_db_transaction is not set in any features, the entire write operation occurs in a single transaction.

This parameter allows for the execution of SQL statements before opening a table for writing. For example, it may be necessary to drop a constraint 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 help.

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

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.