I ran into this same CSV encoding compatibility issue last year and here’s the complete solution that worked:
1. CSV Encoding Compatibility:
First, ensure your CSV files are saved with UTF-8 BOM encoding. The BOM header tells Crystal Reports explicitly that the file is UTF-8. Most ERP systems have an export option for this. If not, you can batch convert files using a script.
2. Unicode/ANSI Data Handling:
Crystal Reports 2016 requires proper ODBC configuration for Unicode support. Here’s the fix:
// ODBC DSN Configuration (use odbcad32.exe)
Driver: Microsoft Access Text Driver (*.txt, *.csv)
Options: Enable "Use Unicode" checkbox
Format: Set to "CSV Delimited"
3. ODBC Unicode Support Setup:
In Windows ODBC Data Source Administrator:
- Create new System DSN (not User DSN)
- Select “Microsoft Access Text Driver”
- Click “Options” and check “Use Unicode”
- Under “Select Directory”, point to your CSV folder
- Click “Define Format” and specify CSV format with UTF-8
Alternative Solution:
If ODBC configuration doesn’t resolve it, create a simple ETL process:
// Pseudocode - CSV preprocessing steps:
1. Read CSV file with explicit UTF-8 encoding
2. Validate and normalize special characters
3. Convert to database staging table with NVARCHAR columns
4. Point Crystal Reports to staging table instead of CSV
5. Schedule preprocessing before report generation
// This ensures consistent Unicode/ANSI data handling
Testing:
After configuration, test with a sample file containing: é, ñ, ü, €, £, ¥, ©, ®. All should display correctly. If you still see question marks, the ODBC driver might not support Unicode - in that case, upgrade to a newer ODBC driver version or use the staging table approach.
The key is understanding that Crystal Reports 2016’s direct CSV import has limited Unicode/ANSI data handling capabilities. The ODBC Unicode support configuration is essential for proper special character processing. Let me know if you need help with the specific ODBC settings for your Windows version.