While most results will be identical, here is an example of how the results may be impacted, for most clients this will be less than 1% of your data, but that percentage can vary from client to client so please be aware.
If you were to enter a sample address, in this case this particular address is not deliverable by the USPS, but house number is within an expected range, so its valid down to the street, but not deliverable. These are the only type's of records that will be impacted by this update.
56 Hillcrest Dr
Now lets look at how this would be returned in mSQL:
1) Using the old SHA1 Data with any mSQL version
2) Using the SHA 256 Data with a version from 2.0.2 to 2.3.1 (not compatible with anything before 2.0.2, if you are running anything before 2.0.2 please plan to update before before September 30th)
*note that the DPV will not be returned if you don't upgrade mSQL. and casing will not be fixed, and the invalid +4 will be left as its copying back the original data.
The main columns impacted are Addrscore, and DPV
3) Using 2.3.2 or Newer with the new Disable19 setting enabled (default), accessible from the task under advanced settings.
4) Using mSQL 2.3.2 or Newer with the Disable19 Setting Off
*The DPV is no longer lost, and the PAFFLAG and PafDesc are more appropriate
In findIT S2/matchIT Web
As long as you update to 22.214.171.124 or newer and the new SHA256 data at the same time, you should see no difference in results.
The 19 return code is controlled through a new setting "AllowDPVNoMatch" located in the web.config for the US addressing Web Service, normally in C:\Program Files\matchIT Web\website\USAddressingWebService
On new installs, this will default to True, so as long as you update your version and the data at the same time you should see no difference in results. It will return a code N just like the SHA1 data with older findIT/matchIT Web versions.
If you set the "AllowDPVNoMatch" to false, then it will return a failure for those cases