GenderWise known issues.
Windows 10 Update 1703 Issue
There was an issue with Windows 10 update version 1703 and GenderWise.
If you have updated your Windows 10 with version 1703 and your GenderWise install returns an unhandled exception, you will need to update your GenderWise executable with a new patched executable.
You can download this patched executable here:
Once you have the patched GenderWise executable, replace your current GenderWise executable located in
C:\Program Files (x86)\Melissa DATA\GenderWise with the patched executable you downloaded.
Check for Updates returns an ‘Update Failed: Unable to extract UnZip.Dll’ error.
- The program Update has been changed. To get the new update working, navigate to the folder where GenderWise is installed, and manually delete the UnZip.Dll file. You should be able to use Automatic Update now and for subsequent update releases.
- Some dual names with embedded punctuation will not split correctly (fixed in version 4.000).
Ex. Karl M. Hanson M.D. & Laurie L. Gold
- Some dual name patterns do not get split correctly (fixed in version 4.000).
Ex. ‘Mr. Lastname & Mrs. Lastname’
- In order to simplify the setup process, GenderWise automatically applies the user default Output fields specified in Tools | User Settings every time you create a setup. If these specified fields exist in your database, they will get over-written during processing, even when they are grayed out in the setup, because they are still stored as part of the setup fields to be processed if you don’t remove them (fixed in version 4.001).
- If you already have a gender field, you must select ‘Override Existing Prefixes’, or Genderbase & Correction will not correct the misspelled name (fixed in version 4.000 ).
- The ‘Transform Suffixes’ option does not always work. It will not convert a suffix if the default genderizing process returns a different value (fixed in version 4.001).
Ex. ‘Mr. Smith MD’ returns ‘Dr. Smith MD’, but ‘John Smith MD’ returns ‘Mr. Smith’
- Regional address patterns, where key words have different meanings than are currently coded as in the lookup table, may not split correctly.
Ex. “5765 E LOOP 281 S”
- If you create ‘Output Line 1’ and ‘Output Line 2’, the street address will get dropped if a PO Box is present, even if you use the default settings or custom settings – which should retain the street address (fixed in version 4.000).
- ‘Output Line 3’ will never get populated (fixed in version 4.000).
- Options: If you select ‘Convert Numbers to Ordinal Literals’, it will change ‘6 St’ to ‘Six St’, but changes ‘Main St’ to ‘ZERO Main St’ (fixed in version 4.000).
- Highway patterns like ’42 N State Highway 6 W’ do not split correctly (fixed in version 4.000).
- Records with embedded spaces separating zip5 – zip4 will not get zip code parsed correctly (fixed in version 4.000).
Ex. “02066-1337” splits correctly “02066 – 1337” does not
- Processing Canadian records with the province ‘NF’ will not be changed to ‘NL’, the newer abbreviation, it is hard coded (fixed in version 4.000).
- If you ‘user mark’ records in Tools | Browse ( ctrl+U ), then Analyze | Errors, the count will be 0, but you can browse, edit, and remove them (fixed in version 4.000).
- dBase functions padc, padl, and padr do not work (fixed in version 4.000).