FAQ:SSIS:Known Issues: Difference between revisions
Line 9: | Line 9: | ||
This is a Microsoft SSIS issue, we provide both 64bit and 32bit dlls but 32bit dll is not supported by Melissa Data. If during processing SSIS uses only the 32bit instead of the 64bit. Please contact your Microsoft technical support to resolve this issue as specific combinations causes this strange behavior. | This is a Microsoft SSIS issue, we provide both 64bit and 32bit dlls but 32bit dll is not supported by Melissa Data. If during processing SSIS uses only the 32bit instead of the 64bit. Please contact your Microsoft technical support to resolve this issue as specific combinations causes this strange behavior. | ||
Known Setup Issues: | ;Known Setup Issues: | ||
Installed SSIS 2012, Using Visual Studio 2012, Visual Studio 2010 Installed | Installed SSIS 2012, Using Visual Studio 2012, Visual Studio 2010 Installed | ||
*Behavior: Uses two 32bit DtsdebugHost and crashes | *Behavior: Uses two 32bit DtsdebugHost and crashes | ||
Known Working: | ;Known Working: | ||
Installed SSIS 2012, Installed Visual Studio 2012, Using Visual Studio 2010 | Installed SSIS 2012, Installed Visual Studio 2012, Using Visual Studio 2010 | ||
*Behavior: Working | *Behavior: Working |
Revision as of 16:45, 7 August 2015
← SSIS:Data Quality Components
SSIS: Global Verify On Premise Crashes
SSIS will crash when specific combination of visual studio and SSIS causes runtime to use only 32 bit processing. We officially only support 64 bit version processing. You can check if the correct behavior is exhibited, by opening process manager and see if there are both 32bit and 64bit DtsDebugHost is running. If only 32bit is running, we do not officially support 32bit run time.
- Resolution
This is a Microsoft SSIS issue, we provide both 64bit and 32bit dlls but 32bit dll is not supported by Melissa Data. If during processing SSIS uses only the 32bit instead of the 64bit. Please contact your Microsoft technical support to resolve this issue as specific combinations causes this strange behavior.
- Known Setup Issues
Installed SSIS 2012, Using Visual Studio 2012, Visual Studio 2010 Installed
- Behavior: Uses two 32bit DtsdebugHost and crashes
- Known Working
Installed SSIS 2012, Installed Visual Studio 2012, Using Visual Studio 2010
- Behavior: Working
Installed SSIS 2014, Using Visual Studio 2013
- Behavior: Working
SSIS: Global Verify License Issue
SSIS will complain about license Issue.
- Resolution
Fixed in patched build 2575. Please download from FTP ftp://ftp.melissadata.com/Updates/DQC-web.exe
SSIS: Matchup UK Matchcode Not Saving
When using the Matchup UK Matchcodes, it doesn't save the UK matchcodes.
- Resolution
Fixed in patched build 2575. Please re-download from the notification email, it has been updated with the fix. ftp://ftp.melissadata.com/Updates/DQC-web.exe
SSIS: Personator Not Verifying
When using the Personator Verify option, no verify result codes are coming back. ftp://ftp.melissadata.com/Updates/DQC-web.exe
- Resolution
Fixed in patched build 2575. Please redownload from the notification email, it has been updated with the fix.
Upgrading Global Address with Global Name, Phone, and Email
Current users of the Global Verify Component who are only subscribed to Global Address Check and want to upgrade using either Global Name, Phone or Email, are required to re-install the components and enter their new license string in the installer.
Upgrading your license in the Component GUI using File > Advanced Configuration will currently not work. Alternatively, you can manually change your license string by editing the GlobalVerify.SSIS.Config under:
C:\ProgramData\Melissa DATA\GlobalVerify
and replace your license string for this entry:
<License>ENTER NEW LICENSE HERE</License>
Save the file and open SQL Server Data Tools. You should now be able to use the Global Verify Component with Global Address, Name, Phone and Email.
SSIS: Matchup - Date Keys are Not Being Built Correctly
When using the Component Type: Date in your MatchCode, Date Keys sometimes do not get built in the MatchKey. This is due to a conflict in the expected input format for Dates. Date Inputs should be in the format 'yyyMMdd'. This becomes problematic particularly for some DBMS. SQL Server for example may have a Date Column defined with char[30]. This causes trailing spaces to be included in the Date Input which conflicts with the expected Input Format, causing the Date Key to not be built.
- Future Resolution
We will be adding a fix in a later build to trim the trailing white spaces for Date Inputs.