Issue  

Chinese, Latin, and other special characters are not stored correctly in a MSSQL database when it is the target database.  Instead, BIX inserts '??' placeholders.  

This occurs even if the DDL generated by BIX for the target database is used to create the target table. 

Symptoms and Imact

BIX Extract output to MSSQL databases displays incorrect data.

 Steps to Reproduce 

1. Save Chinese character in a Pega Data Table (Records -> SysAdmin -> DataTable). Note that the column type is NVARCHAR, with supported Unicode (SQL_Latin1_General_CP1_CI_AS).
2. Verify that the DB collation settings for the target table support Unicode (SQL_Latin1_General_CP1_CI_AS). 
3. Run a BIX Extract with a MSSQL Database as the target.    
4. After extraction the special characters are replaced with invalid characters ???????. 

Root Cause   

This is a feature gap.  BIX refers to the column type based on the property type and will insert into a VARCHAR. 

• VARCHAR stores text using a single-byte code page (collation/codepage dependent). Characters not representable in that code page will be lost or converted (often to the character ?) during conversion. 
• NVARCHAR stores Unicode (UTF‑16LE), so it can represent essentially all characters reliably (accents, non‑Latin scripts, emoji/symbols, etc.). 

The application sends “special characters” into a VARCHAR column, and SQL Server silently corrupts those characters depending on the database/code page.  

In the platform data layer code JDBC, column type is recognized as NVarchar and the JDBC setNString is called, which essentially appends N' in front of the text for the nvarchar column.   

In SQL Server, the N prefix marks a string literal as Unicode (an NVARCHAR literal). 

• 'text' → interpreted as VARCHAR literal (code page based) 
• N'text' → interpreted as NVARCHAR literal (Unicode) 

So: 

INSERT ... VALUES ('café')  

'café' is a VARCHAR literal; if the code page can’t represent é, you risk conversion/loss. 

INSERT ... VALUES (N'café')  

N'café' is Unicode, so é is preserved. 

Solution  

Make the following local changes:   

1. Include sendStringParametersAsUnicode=true in your JDBC connection URL. 

2. Change the column type in the target table to NVARCHAR(MAX) instead of VARCHAR.

For example:  

ALTER TABLE pegadata.TargetDB ALTER COLUMN "FName" NVARCHAR(MAX) NULL   

The issue is due to be fixed in upcoming Pega Platform releases. 

References

Working with CSV Files in Pega Platform