Pitney Bowes MapMarker USA - Manual (Page 196)

Additional Considerations for Remote Table Geocoding
196
MapMarker USA 25
You or your database administrator must be familiar with how the two tables are related. If the tables
use multiple keys, you must set the relationship before starting any geocoding. Be familiar with your
data and table structure to ensure the geocoding output results are valid.
Additional Considerations for Remote Table Geocoding
Consider the following when doing any type of remote table geocoding:
Sort by ZIP Code™ for Faster Geocoding on page 196
Geocoding Unmatched Records on page 196
Transaction Control with ODBC Tables on page 196
Remote Database Views on page 197
Rollback Segment Limit on page 197
Supported Unique Index and Primary Key Data Types by Database on page 197
Sort by ZIP Code™ for Faster Geocoding
MapMarker performance is best when it can access records sorted by ZIP Code. For local tables,
therefore, we recommend that all tables for geocoding are sorted by ZIP Code prior to geocoding.
For remote tables, we recommend that the ZIP Code column be indexed for faster accessing. To
add an index to a remote table, follow the instructions for your database.
Geocoding Unmatched Records
MapMarker can geocode unmatched records in previously geocoded remote tables instead of
geocoding the entire table with every pass. After you select the input and output columns, go to the
Geocode dialog and set the types of rows to geocode to Unmatched Rows. MapMarker attempts to
find a match for all records in your table that have a georesult of N or blank. MapMarker updates the
log file to reflect the total number of records it attempted to geocode during the pass, not the total
number of records in the table.
L
Geocoding unmatched records is not available for multi-table geocoding.
Transaction Control with ODBC Tables
MapMarker uses as non-obtrusive locking mechanism as possible when geocoding your ODBC
table. It attempts to use the lowest level of locking available (for example, row, page or, at worst
case, table locking). Locks are not placed until the row is geocoded. MapMarker issues a commit
after each update so that each lock is held for an extremely short time (the time it takes to lock a row,
update it, and commit it).