Check Limits for Large Tables and Long SQL Statements

Script length, table width and the editor's input limit are separate constraints. With this cookbook's Dharma 14.01 driver and 5.5.4 gateway, SQLGetInfo returned:

All 22 calls succeeded on a fresh connection to this edition. The DBMS version above identifies the ODBC SQL component; it does not replace the APPX engine version. A reported 0 does not establish an unlimited, usable capacity: no maximum may be specified, the limit may be unknown, or the property may not apply. These are reported values, not stress-tested maxima. See Microsoft’s SQLGetInfo definitions for each property.

These values belong to this tested combination. Do not apply the older reference's 500-column or 32-character limits, or these newer values, indiscriminately to another APPX/ODBC edition.

What happens near the length limit

The 5.5.4 ASQL source retrieves generated SQL in chunks and executes its semicolon-separated statements individually. Its Try Again buffer is allocated from the editor's text length; the old fixed 4 KB retry buffer was corrected in 2017. A complete script can therefore contain several statements even when no individual statement may exceed the driver limit.

The ordinary Windows edit control also has a default 32,767-character text-entry limit. That affects typing or pasting; it does not establish the maximum size of an automatic import. Windows permits larger text loaded programmatically. See Microsoft's edit-control limit documentation.

The advertised 35,000-character SQL limit is not a reliable target for this connection. Fresh-connection, read-only probes passed at 32,768 characters but failed at 33,000 through 35,000 with:

ERROR [k0k14] [Dharma][ODBC Dharma Driver 14.01.00.0000][Dharma/SDK] -30034

At 35,001 characters, the driver returned:

ERROR [HY090] [Dharma][ODBC Dharma Driver 14.01.00.0000] -19 Invalid string or buffer length

The first diagnostic did not supply additional message text. These probes establish observed failures, not an exact maximum for every generated CREATE TABLE. Keep individual statements comfortably below 32 KB and inspect the actual error if a wide-file import fails. A failure partway through a multi-statement import can leave some metadata created and other definitions unfinished.

Shorten SQL without changing its meaning

First save the complete script. Remove unnecessary comments and indentation, and use shorter distinct column names with matching index references. Retain complete column declarations, commas, closing parentheses and metadata_only clauses. Execute complete table, index and synonym statements separately if the SQL tool requires that. Splitting the script does not make an oversized CREATE TABLE statement smaller.

Do not simply cut the SQL at a byte count, delete a middle column, or reorder columns. The gateway maps columns to APPX fields by position. Renaming preserves that position; removing a middle column shifts later mappings and can produce wrong values or conversion errors.

If a reduced import is necessary, retaining an unchanged leading sequence of columns and omitting only trailing declarations preserves the earlier positions in the reviewed source. This is an administrator workaround that must be tested against the specific file. Repair the final comma/parenthesis, omit indexes or constraints that reference removed columns, preserve the original script, and compare every retained field with native APPX records. This cookbook's COUNTRY tests do not establish that workaround for an arbitrary large file.

When the full table imports successfully but a client cannot handle its width, leave the base definition intact and select only the required columns, or use a view. For example:

SELECT name AS country_name, region_label, no_words, post_code_loc
FROM DMO_DMO_COUNTRY
ORDER BY name

This reduces the result width without disturbing APPX field mapping. A view cannot repair a base table that has not imported successfully.