Conditional index re-create (same bag+tag, while open) leaves a stale active order under the rddads OrdCreate path - parity gap vs DBFCDX

[russimicro]

Summary

Re-creating a conditional (FOR) order in place - same bag file, same tag name, while that order is still the open/active one - leaves the work area navigating the previous order instead of the new one. The native Harbour DBFCDX RDD handles the same OrdCreate overwrite correctly; through contrib/rddads against the OpenADS local ABI the order does not refresh.

A downstream Harbour ERP hit this while filtering a browse: filtering by one column works, then re-filtering by another column (the app reuses a single temp bag + tag and rebuilds it) leaves the list sorted/filtered by the previous column.

Environment

• OpenADS v1.4.0, MSVC x64 (openace64.dll), Windows.
• Harbour contrib/rddads as the client RDD.

Repro (client / rddads pattern)

// browse work area cAliTab already open
OrdCondSet( cFor1, ...,.T. )                 // FOR for column A
OrdCreate( cFilTmp, "ORDERX", cKeyA )        // build & activate ORDERX (col A)
// ... browse shows column-A order, filtered ...

OrdCondSet( cFor2, ...,.T. )                 // FOR for column B
OrdCreate( cFilTmp, "ORDERX", cKeyB )        // SAME bag + SAME tag, NOT closed first
// expected: browse now ordered/filtered by column B
// actual  : browse still navigates the column-A order

Expected

After the second OrdCreate, the active order reflects the new key expression + new FOR (column B).

Actual

The active order still reflects column A. Under DBFCDX the same sequence re-sorts correctly.

What I could verify at the engine/ABI level

Direct ACE-API unit tests of the same overwrite pass - the engine produces the correct order and key set (tests/unit/abi_conditional_index_refilter_test.cpp): same bag + tag "ORDERX" overwritten with a different expression / key length / FOR, including an AdsCloseAllIndexes (ORDLSTCLEAR) between creates. KeyCount, OrdKeyNo, goto_top/skip/EOF and AdsGetNumIndexes are all correct after the re-create.

So the gap appears to live in the rddads <-> local-ABI interaction when the temp .cdx is still open at re-create time, not in AdsCreateIndex61 itself.

Hypothesis (for maintainers)

On Windows the client's FERASE cannot delete the still-open temp .cdx, so the second OrdCreate overwrites the tag in an already-open bag; the order metadata keyed by the same bag-path + tag-name may be reused rather than refreshed, so the active-order pointer/cursor is not rebound to the new tag. A clean repro through the public Harbour contrib/rddads harness would confirm which side needs to invalidate.

Downstream workaround (not a fix)

The ERP closes the temp bag before the next OrdCreate, gated to the ADS RDD only so DBFCDX is untouched:

IF "ADS" $ (cAliTab)->( RDDNAME() )
   TRY
      (cAliTab)->( OrdSetFocus(0) )
      (cAliTab)->( OrdBagClear(cFilInd) )
      FERASE(cFilInd)
      IF FILE(cFilInd)
         (cAliTab)->( OrdListClear() )
         FERASE(cFilInd)
      ENDIF
   CATCH
   END
ENDIF

Related

Companion fix already in main: fix: AdsCreateIndex (7-arg) honors the FOR condition (commit 7e0cee2).