fix(cdx): a character key that merely contains Val() is not a numeric key - #137
Closed
russimicro wants to merge 1 commit into
Closed
fix(cdx): a character key that merely contains Val() is not a numeric key#137russimicro wants to merge 1 commit into
russimicro wants to merge 1 commit into
Conversation
… key The FiveTechSoft#130 heuristic marks a tag as a CDX numeric key whenever its expression contains the substring "VAL(" anywhere. That misfires on the rddads/Clipper idiom INDEX ON cDocumeTra + STR(VAL(cConIntTra), 3, 0) TAG ... which concatenates text — STR() returns characters, so the key is character data 8 + 3 wide. Marked numeric, the build loop demands a number from the concatenation and aborts partway through the table with ADSCDX/5000 "failed to evaluate numeric index expression". The syntactic fallback now fires only when the WHOLE expression is that call: the ')' closing the leading VAL( must be the final character. A bare Val(charfield) (FiveTechSoft#130) still gets the 8-byte Fox numeric key — its seek test and the key_length == 8 test stay green. New test abi_cdx_str_val_compound_test builds the tag, walks it in key order, and pins key_length == 11 (character), not 8. Hit on a Harbour/FiveWin ERP's monthly movement tables: 7 such tags in a single reindex, 56 occurrences of INDEX ON ... VAL( across the application. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
Owner
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The #130 heuristic marks a tag as a CDX numeric key whenever its expression contains the substring
VAL(anywhere:That misfires on the rddads/Clipper idiom
which concatenates text —
STR()returns characters, so the key is character data 8 + 3 wide. Marked numeric, the build loop demands a number from the concatenation and aborts partway through the table with:The syntactic fallback now fires only when the whole expression is that call: the
)closing the leadingVAL(must be the final character. A bareVal(charfield)(#130) still gets the 8-byte Fox numeric key — its seek test and thekey_length == 8test stay green.Test:
abi_cdx_str_val_compound_test— builds the tag, walks it in key order, and pinskey_length == 11(character), not 8.Hit on a Harbour/FiveWin ERP's monthly movement tables: 7 such tags in a single reindex, and 56 occurrences of
INDEX ON ... VAL(across the application, so it is not an exotic shape for rddads code.Suite: 1178/1190 — the same 12 pre-existing SQL-parser (7200) failures as pristine v1.8.31, verified on this branch in isolation (MSVC x64 Release).
Same deployment as #134, #135 and #136.
🤖 Generated with Claude Code