DatabaseJoiner

Features that successfully matched.

Features that had no matches.

If Cardinality is set to Must Match Exactly One or Must Match Zero or One, then features that do not meet the criteria are rejected.

Select the Reader format and dataset where the table resides, including any format-specific parameters.

Specify the table to join. Click the Browse button to select the table from a list. Note that you can only select this after you have completely specified the reader format, dataset, and format-specific parameters.

Select the attribute(s) from the incoming feature and their corresponding table field(s) that will be used to find matches. Matches are made when the values of all the attributes equal the values of their corresponding table fields.

There is one row for each attribute and column pair in the table entry widget. You can add more pairs by clicking the plus (+) button located to the right of the table. Similarly, you can remove pairs by pressing the minus (-) button. A minimum of one pair must be specified for the join to work.

Select attributes from a drop-down list in the Feature Attributes column. (You can type directly in the corresponding table fields or select from a list by clicking the Browse button.) For the Browse button to list available table fields, all the information needed to read from the table needs to be specified.

Specify a list of fields from the matching table rows to join onto the incoming feature.

To select the fields from a list, click the Browse button. A dialog showing the list of possible fields will appear. Place a check next to each field you wish to add, and click OK.

If no fields are specified, all the fields from the matching rows will be added.

Indicate the type of relationship between the database rows and each feature. This will describe how many rows will match to each feature and what action the DatabaseJoiner will take if the expected number is not found.

Note: The Must Match rules are very strict. When in doubt, use Match First or Match All.

Specify how results of multiple matches will be given.

Create a feature for each match: Each row matched is added to a copy of the incoming feature. In this scenario, for each feature in, there will be matched features out. If there are no matches, the feature exits the Unjoined output port.

Add fields on a list attribute: Each row matched is added to a list attribute on the feature. If there are no matches, the feature exits the Unjoined output port.

The name of the list attribute to append multiple matches.

Note: List attributes are not accessible from the output schema in Workbench unless they are first processed using a transformer that operates on them, such as ListExploder or ListConcatenator. All list attribute transformers are displayed in the Contents pane of the Transformer Help under Lists. Alternatively, AttributeExposer can be used.

If Merge Joined is chosen, attributes from the feature and table will be merged, and in case of conflicts the value specified in the Conflict Resolution parameter will be used. If Prefix Joined is chosen, then all incoming attributes will be presented with a prefix set in the Prefix parameter.

This parameter is enabled when Accumulation Mode is set to Merge Joined. Use Original and Use Joined will give priority to original and incoming attributes respectively in case of attribute conflicts.

The specified value is used as a prefix for incoming attributes when Accumulation Mode is Prefix Joined.

Normally the cache is filled with records as they are matched in the database. However, for formats that support SQL, the cache can be preloaded (that is, filled with a specific set of data before matching takes place) by issuing a prefetch query. This prefetch query can select an entire table or a selected part of a table which is most likely to be matched by the feature attributes.

Note: Unless the prefetch query is exhaustive, cache size limits apply. See Prefetch Exhaustive to learn what constitutes an exhaustive prefetch query

A prefetch query which is known to retrieve all possible matches is called an exhaustive query.  When a match cannot be found within the cached results of an exhaustive query, it is assumed that no match exists in the database; thus the database will not be further consulted.

If Prefetch Exhaustive is set to Yes, this indicates whether a prefetch is exhaustive. Even when it is set to No, however, any prefetch query is assumed to be exhaustive when it does not contain a WHERE clause, and is of the form:

SELECT * from TableName

Note: When FME considers a prefetch query to be exhaustive, the cache size limit will be ignored. This is because the cache must contain all results from the query.

For example, a number of FME features of type "roads" require a database match. The database table (myrecords) has a field (record_type) with a number of values; roads, highways, avenues, streets. The FME features will only ever be matched to where record_type=roads so the overall join process would be much more efficient if the following prefetch was issued:

SELECT * from myrecords where record_type = 'roads'

Specify the number of rows to cache locally if you do not want to accept the default of 5000. You can optionally specify an SQL query to preload the cache. Note that cache size is ignored if the prefech query is exhaustive.

Engaging trimming of key fields may significantly reduce performance and should only be done if key column values in the database are known to contain trailing spaces.

It has no effect if an exhaustive prefetch query is used (see above for an explanation of Prefetch Exhaustive).

Note: This parameter is included for backwards compatibility and most users will have no need to use it. The parameter can only be accessed using the pane of the Workbench.