Check Limits for Large Tables and Long SQL Statements

Script length, table width and an editor's text-entry limit are separate constraints. The supplied Dharma 9.01 driver with the 5.5.2 gateway reported these values through SQLGetInfo:

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 limits differ from the updated driver used in the 5.5.3 and 5.5.4 editions. See Improvements in Later Releases for the tested later combinations and their larger reported table/name capacities. Keep them with this version and driver combination. A reported limit does not guarantee that every statement of that size will execute successfully.

The reviewed release-5.x ASQL source requests the generated script in 2,048-byte chunks and executes semicolon-separated statements individually. The gateway writes generated DDL to a script file and returns requested chunks. Source constants named MAX_SCRIPT_LEN are not, by themselves, proof of a whole-import limit. The packaged ASQL executable carries an older file-version label; verify the actual editor behavior rather than assuming every later source change is present in that executable.

A failure after one successful CREATE can leave a partial definition. Preserve the full SQL and error, check which tables, indexes and synonyms exist, then arrange a controlled retry. Do not repeatedly import a whole application folder to diagnose one wide file.

Observed long-statement errors

Fresh-connection, read-only catalog queries passed at 32,768 characters, but failed at 33,000 through 35,000 characters with:

ERROR [00000] [Dharma][ODBC Dharma Driver 09.01.0000][Dharma/SDK] -20217

At 35,001 characters the driver returned:

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

The first diagnostic supplied no additional text. These probes establish observed failures, not an exact maximum for every generated CREATE TABLE. Keep statements comfortably below 32 KB and inspect the complete error if an import fails.

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.