Review 431: dc-overview.md still said "Up to 500 rows can be edited (in the web
editor) at one time" - the wrong number (DC_MAXOBS_WEBEDIT ships at 250) and, once
dc/dc#352 lands, the wrong behaviour (an over-limit selection is served truncated
with a warning, not refused or capped at a count). It now names both limits,
whichever binds first, and links to the options that set them.
Sweeping for the same stale figure turned up dcu-tableviewer.md, which says 500
twice and uses 500 in its worked example of the row count above the grid.
DC_MAXOBS_WEBVIEW has been 2000 since 20261003_row_and_cell_limits.sas (the
migration records 500 -> 2000), and mpe_makedata seeds 2000, so those three
places were two releases out of date. Fixed here, and flagged in the PR reply as
VIEW rather than EDIT in case it belongs in its own change.
Checked: no "500 rows" or stale abort wording left in docs/, and the two anchors
the overview now links to (dc_maxobs_webedit, dc_maxcells_webedit) exist on the
published options page.
Follow-up to the previous commit on this branch, both wording fixes.
- The sentence this branch deleted was the page's only description of the row
count when no search is active - and that is the case where the count really
can exceed the rows displayed (viewdata reports count(*) for the filtered
view while the grid stops at DC_MAXOBS_WEBVIEW). State it, instead of leaving
the page silent on the path readers use most.
- "returns the first 500" claims an ordering the search does not apply: the
search is a WHERE clause with no ORDER BY, so which 500 come back is whatever
the engine hands over first. Say "returns 500 of them".
Checked against viewdata.sas and mp_searchdata.sas on main: the search path
passes outobs=DC_MAXOBS_WEBVIEW to mp_searchdata, which caps the result dataset
in the same data step that builds it, and viewdata takes its row count from that
dataset - so for a search the count and the rows are capped together.
The row count next to the table name is the capped count, not the total
number of matches. A search that matches more rows than DC_MAXOBS_WEBVIEW
returns the first 500 and reports 500, so the count does not rise above the
cap even when many more rows match.
The example claimed `smith` finds `Smithson`, which only holds for a case
insensitive match. The search is a case sensitive CONTAINS match - DC passes
the search value straight to %mp_searchdata, which uses the SAS `?` operator -
so `smith` finds `Goldsmith` (a lowercase substring) and not `Smithson`.
The "Full Table Search" section said only that a search box exists. It now
states the behaviour that users actually hit:
- the search covers every column at once, character columns by case sensitive
CONTAINS and numeric columns by exact match
- the Numeric toggle switches to exact numeric matching
- an applied filter scopes the search
- results are capped by DC_MAXOBS_WEBVIEW (linked to the options page), and the
row count next to the table name reports the match count
- a search with no matches shows the "No data found with given conditions"
panel
Adds a screenshot of the search in action (docs/img/full-table-search.png),
captured from a running instance via the Cypress suite in the dc repo.
dc
allan