Modifying Settings for RightFielder Object#

The data directory for Right Fielder Object includes a plain text file named mdRightFielder.cfg, which allows you to add to and override some of RightFielder Object’s default token recognition. You can add entries to and remove entries from the installed tables of:

  • [LeftToken] = List of words/phrases that commonly appear at the start of data (ie, name, company, title identifiers).

  • [MiddleToken] = List of words/phrases that commonly appear in the middle of the data (ie, street address identifiers).

  • [RightToken] = List of words/phrases that commonly appear in at the right end of the data (ie, city, state, zip, country identifiers).

  • [LeftPattern] = Identifiable sequences of [LeftTokens].

  • [MiddlePattern] = Identifiable sequences of [MiddleTokens].

  • [RightPattern] = Identifiable sequences of [RightTokens].

  • [PreProcessRegEx] = Regular expression search/replace that is performed on the raw input data before any other processing. This is often used to handle special anomolies in your data.

  • [PostalCodeRegEx] = Regular expressions used to identify postal codes.

  • [PhoneRegEx] = Regular expressions used to identify and extract phone numbers.

  • [PhoneTypeToken] = List of words commonly used to identify phone numbers (Cell, Fax, etc)

  • [EmailRegEx] = Regular expressions used to identify and extract e-mail addresses.

  • [EmailTypeToken] = List of words commonly used to identify e-mail addresses (E-Mail, Email, etc)

  • [URLRegEx] = Regular expressions used to identify and extract URLs.

  • [URLTypeToken] = List of words commonly used to identify e-mail addresses (URL, website, etc)

Each section of the file begins with the name of the table enclosed in square brackets. To add an entry to the table, simply add a line to that section. If that entry duplicates one in the default table, mdRightFielder uses the entry in the configuration file, allowing you to override the original settings.

To remove an existing entry from the default table, begin the line with a dash or minus sign (“-“).

An entry consists of a single line of text containing several values separated by commas.

For example, a line in the LeftToken section of the file must follow this format:

<token>, <tokenType>

Replacing each placeholder with a real value, the actual entry might look like this:


Unused values at the end of a line are optional. Empty values in the middle of a line must have the necessary comma.


This is an advanced topic, with descriptions and syntax for overriding the default tables are in the actual mdRightFielder.cfg. Please contact Melissa Data support with questions or advice before editing these tables, as any changes can significantly change the default behavior of the processor.

Best Practices#

Order Input Data in a Logical Order#


If your database structure has columns in a non-intuitive order, reorder the respective columns to represent a more common order (think of the order for a mailing label). This will help RightFielder process more accurately.

Example Table layout: ADDRESS FULLNAME CSZ


Maintain Hard Delimiters (and Placement)#


If the the table to be processed originally had hard delimeters (tab, pipe, crlf), maintain or restore these delimiters before processing with RightFielder. This will help Right Fielder process more accurately.


Recommended structure: FULLNAME | FULLNAME2 | ADDRESS | CSZ

Only Process required Fields#


If the table contains un-needed fields or proprietary data types, do NOT add them to the input data to be processed (unless you have created a SetUserPattern to handle them).


Recommended input: FULLNAME | ADDRESS | CSZ


If the BANKACCOUNT numbers are always formatted in a consistent manner, create a SetUserPattern for accurate processing.

Maintain a consistent design of Source Data#


Good input design. How is the data to be RightFielded collected? If you are developing a user interface with edit controls for input, design for multi-row input which can be padded with hard delimiters by your application.

Customize handling for Proprietary data types#


If you have proprietary data embedded throughtout your source data, create a valid regular expression examples for the SetUserPattern method. This helps RightFielder identify an unknown data format - like a part number or an account number for example - and will place it in its own category.

See the RightFielder documentation and mdRightFielder.cfg example for more details.

Over-ride the distributed Data Files for keywords with alternate meanings#


Data File override. RightFielder allows you to add or override the behavior of known keywords contained in the default data file mdRightFielder.dat. Open the mdRightFielder.cfg file in a text editor for instructions, syntax and examples on how to do this.

Example: Xyz Smith.

Depending on the rest of the input tokens, it may not be recognized as a name, but adding ‘Xyz’ as a name in the cfg file will help process records with previously undefined tokens.

Supply data beyond minimum input#


One of the previous Best Practices recommends against processing too much input. Isn’t this suggestion contrawise?

No, configuring RightFielder is a fine line between not enough input and too much input. Since tokens can have multiple meanings, input data will be more accurately fielded if a minimum input is met. While no strict standard can be applied, an input that represents a true contact record should be expected to process more accurately than an input record with a single input token.

Example, less than minimum input: sven miller

Example, more data: sven miller | anytown, ma 01234

Config Example#


Data Coverage by Country#


Release Schedule#

Release Date Schedule