fix(abi): report ADS_DATABASE_CONNECTION only for a dictionary connection - #141
Merged
FiveTechSoft merged 1 commit intoJul 29, 2026
Merged
Conversation
…tion AdsGetHandleType returned ADS_DATABASE_CONNECTION for every connection handle. In the ACE SDK that value means "connected to a DATA DICTIONARY", not merely "is a connection", and Harbour's rddads calls it first thing: seeing it, the RDD takes its dictionary path and opens every table with ADS_DEFAULT, expecting the dictionary to resolve the format. ADS_DEFAULT falls back to DBF, so an ADT table (the ERP keeps them as .DAT, so the extension gives nothing away either) gets parsed as a DBF: 258 phantom fields with garbage names for a 148-field table. rddads reads field 1, gets name "0u" and type 99, cannot map it, and aborts the USE with EG_CORRUPTION / EDBF_CORRUPT and an empty description — while every ACE call still returns AE_SUCCESS, so AdsGetLastError() reads 0 and the real cause is invisible from the application. A connection now reports ADS_DATABASE_CONNECTION only when it actually carries a dictionary (Connection::has_dd()); a free-table connection reports ADS_NONE. Remote connections are unchanged. Found by replaying the ERP's exact activation sequence through real rddads in a headless Harbour program, then tracing the ACE entry points. Suite 1188/1200 — the same 12 pre-existing SQL-parser (7200) failures. 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. |
FiveTechSoft
added a commit
that referenced
this pull request
Jul 29, 2026
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.
AdsGetHandleTypereturnsADS_DATABASE_CONNECTION(6) for any connection handle. In the ACE SDK that value means "connected to a data dictionary", andrddadscalls it as its very first call on a connection.Seeing it,
rddadstakes its dictionary path and opens every table withADS_DEFAULT(TYPE=0), expecting the DD to resolve the format.ADS_DEFAULTfalls back to DBF, so an ADT table gets parsed as a DBF:"0u"with type 99EG_CORRUPTION/EDBF_CORRUPTwith an empty descriptionand because every ACE call did return
AE_SUCCESS,AdsGetLastError()is 0 — there is nothing to point at. A free-tables connection over an ADT directory simply cannot open a single table.Fix: report
ADS_DATABASE_CONNECTIONonly when the connection actually has a dictionary (Connection::has_dd()); a free-tables connection reportsADS_NONE.Diagnosed with a headless Harbour program driving the real
rddadsplus tracing at the DLL entry points; C++ probes do not reproduce it because they open withADS_ADTexplicitly. Validated in a production GUI against real data.Suite: 1207/1225 — identical to
origin/mainon this machine (18 pre-existing failures, same files).