fix(plugin-oracle): keep NCHAR text on a non-Unicode database charset

[datlechin]

Why

On an Oracle database whose own character set is not Unicode (WE8MSWIN1252 measured), saving Lao text into an NCHAR, NVARCHAR2 or NCLOB cell stored ¿¿¿ with no error, and an update or delete matched on such text edited the corrupted row or none. The grid wrote the value as a plain literal, which the server converts through the database character set before the national one.

Change

• Grid saves write non-ASCII text for NCHAR, NVARCHAR2 and NCLOB columns as UNISTR('\0EA5...'), in SET, VALUES and row matches. ASCII text keeps the plain literal.
• Each UNISTR call stays under 4,000 bytes both as a literal and as its result; NCLOB pieces are joined through TO_NCLOB. A single call past that limit was silently cut to 2,000 characters on AL16UTF16.
• check-oracle-national-charset.sh writes and matches the way a grid save does.

Verified

Unit tests for the writer. The probe passes on WE8MSWIN1252/AL16UTF16, AL32UTF8/UTF8 and AL32UTF8/AL16UTF16: writes, NVARCHAR2 and padded NCHAR matches, a 1,000,000-character NCLOB.

Not in this PR

• Filters, the filtered count, FK lookups, copy as SQL, export, import, Copy To and query parameters still send this text through the database character set. They need column types the plugin does not get today, so a PluginKit addition.
• iOS writes the same plain literals.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
TablePro	🟢 Ready	View Preview	Oct 8, 2026, 9:21 AM

💡 Tip: Enable Automations to automatically generate PRs for you.