Frequently Asked Questions

Should I use Name 2? / MPMileage does not recognize my pushpins

Do not use the "Name 2" column type setting when you import your locations into MapPoint. MapPoint will create new pushpin names by concatenating the Name and Name 2 columns. These will never match the Name column you are using in MPMileage, so avoid "Name 2" completely.

Note: MapPoint will often default to using the "Name 2" column type if you have more than one column that looks like a name. Select the correct column for "Name", and set the other column to "Skip Column".

How can I improve the processing speed?

MPMileage has been written to take advantage of modern processors, and hence can perform route calculations much more quickly than MileCharter. However, some of this speed depends on a correct configuration. Here are some suggestions for speed:

•Make sure your database has an index on the start and end location fields. These two fields are used as references for both reading and writing the data. Note that indexes cannot be applied to Excel workbooks. Large datasets should be implemented using a proper relational database using Microsoft Access or via an ODBC connection.

•Make use of all available CPU cores by setting the Number of processing threads setting on the main panel. This may require some experimentation. Both the operating system and the database require some overhead, so the optimum may be less than one processing thread per core. Tests have shown that four threads on a quad core computer work well. On a fast no-load computer with a fast, local database, there may be some advantage gained from also using the hyper-threaded cores (eg. specifying 6 or even 8 threads on a hyper-threaded quad core PC).

•Remove duplicate rows from the input data. MPMileage is clever enough to avoid duplicate route calculations, but duplicates will always slow data reading and writing.

MPMileage does not want to write numeric values to Excel

All output values, regardless of the database, are written in the format of the data field. Unlike a true relational database, Excel is weakly typed. Therefore it is possible for a cell or column to appear to be blank or un-typed, but Excel reports it as being text.

The solution is to clear the entire column, and then format it as a number with two decimal places. You may have to re-enter the column header (if there is one).

MPMileage does not recognize the Excel columns that store my location names

This usually occurs if your location names are numbers. Location names are often numbers if you are using your own numeric identifiers, or if you are using zipcodes.  Excel is weakly-typed and will usually treat these as numbers. However, the locations must be text for MPMileage to recognize them, and for MapPoint comparisons to work properly.

It is strongly recommended that you use use a proper strongly-typed database (eg. Access or an ODBC connection) for applications like this. However, if you must use Excel, format the entire column as text and precede each and every value with a quote (') character. The quote character tells Excel that the field is text and not a number.  An alternative is to use text location names.

I cannot open my Excel workbook when MPMileage is loaded

This is a side-effect of the Excel database driver. You have to exit MPMileage in order to view the workbook. This is another reason to switch to a proper database such as Access.

MPMileage reports that MapPoint failed to start

This error may occur at the very beginning of processing, if MapPoint is not installed properly.

It is also possible that MPMileage might suddenly encounter an error when attempting to restart MapPoint. This may be due to the operating system being busy, and the "start MapPoint" request timing out. MPMileage will report the error and give you the option of trying again, or stopping processing. If the problem was caused by an operating system alert, clear the alert before continuing processing.

MPMileage opens a table but cannot see any/all of the columns

MPMileage must have read/write access to both the table and the columns. This is also true for the location columns. The only exception is the primary key column, which can be read-only.