#5 documented the row count next to the table name as "the number of rows the search matched, which can be higher than the number of rows displayed". Measured against a live Viya estate, that is not what a search does.
Searching a 1200-row table for a value present in every row:
rows reported
rows returned
search (1200 matches)
500
499
plain view, no search
1200
500
For a search, both numbers stop at DC_MAXOBS_WEBVIEW - the count is the capped count, not the match total. The "count higher than displayed" behaviour belongs to the unsearched view, not to the search. (The 499 came from an off-by-one in the search branch of viewdata.sas, fixed separately.)
The bullet now reads:
The result set is capped by the DC_MAXOBS_WEBVIEW option (500 rows by default). A search that matches more rows than the cap returns the first 500, and the row count shown next to the table name is that capped count, not the total number of matches.
Everything else added by #5 held up against the same estate - the case sensitive CONTAINS wording (Smith finds Smithson, smith finds Goldsmith, smith does not find Smithson), the exact numeric match, every-column coverage, the filter scoping, the no-data panel text, and the screenshot.
Follow-up to #5, which was merged before this correction could be added to it.
#5 documented the row count next to the table name as "the number of rows the search matched, which can be higher than the number of rows displayed". Measured against a live Viya estate, that is not what a search does.
Searching a 1200-row table for a value present in every row:
| | rows reported | rows returned |
|---|---|---|
| search (1200 matches) | 500 | 499 |
| plain view, no search | 1200 | 500 |
For a search, both numbers stop at `DC_MAXOBS_WEBVIEW` - the count is the capped count, not the match total. The "count higher than displayed" behaviour belongs to the unsearched view, not to the search. (The 499 came from an off-by-one in the search branch of `viewdata.sas`, fixed separately.)
The bullet now reads:
> The result set is capped by the `DC_MAXOBS_WEBVIEW` option (500 rows by default). A search that matches more rows than the cap returns the first 500, and the row count shown next to the table name is that capped count, not the total number of matches.
Everything else added by #5 held up against the same estate - the case sensitive CONTAINS wording (`Smith` finds `Smithson`, `smith` finds `Goldsmith`, `smith` does not find `Smithson`), the exact numeric match, every-column coverage, the filter scoping, the no-data panel text, and the screenshot.
Follow-up to #5, which was merged before this correction could be added to it.
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.
Reviewed the full diff at 206d88c (one docs file), verifying the changed row-count claim against the viewer code path (viewdata.sas caps both the search result and the reported count at DC_MAXOBS_WEBVIEW; viewer.component.html:433 renders sasparams NOBS). No CI workflow runs on pull requests in this repo and there is no semantic-release, so no pipeline or release-message concerns apply.
docs/dcu-tableviewer.md:24 - the sentence hardcodes the default as fact: "returns the first 500" and "that capped count". DC_MAXOBS_WEBVIEW is configurable (viewdata.sas:179-184 falls back to 500 only when the option is unset), so the text is wrong for any non-default setting. Phrase it against the option - for example "returns only the first DC_MAXOBS_WEBVIEW rows (500 by default), and the row count shown next to the table name is that capped count" - matching the option-reference style of the same line.
repo root - no .pre-commit-config.yaml exists in this repository (and no other gitleaks pre-commit hook), so nothing scans staged content for secrets at commit time. Add .pre-commit-config.yaml with a gitleaks hook pinned to an exact release tag, for example repo: https://github.com/gitleaks/gitleaks, rev: v8.30.1 or the current release, hooks: - id: gitleaks. Standing all-repo requirement - flagged until it lands.
2 findings above for review.
Reviewed the full diff at 206d88c (one docs file), verifying the changed row-count claim against the viewer code path (viewdata.sas caps both the search result and the reported count at DC_MAXOBS_WEBVIEW; viewer.component.html:433 renders sasparams NOBS). No CI workflow runs on pull requests in this repo and there is no semantic-release, so no pipeline or release-message concerns apply.
- docs/dcu-tableviewer.md:24 - the sentence hardcodes the default as fact: "returns the first 500" and "that capped count". DC_MAXOBS_WEBVIEW is configurable (viewdata.sas:179-184 falls back to 500 only when the option is unset), so the text is wrong for any non-default setting. Phrase it against the option - for example "returns only the first DC_MAXOBS_WEBVIEW rows (500 by default), and the row count shown next to the table name is that capped count" - matching the option-reference style of the same line.
- repo root - no .pre-commit-config.yaml exists in this repository (and no other gitleaks pre-commit hook), so nothing scans staged content for secrets at commit time. Add .pre-commit-config.yaml with a gitleaks hook pinned to an exact release tag, for example repo: https://github.com/gitleaks/gitleaks, rev: v8.30.1 or the current release, hooks: - id: gitleaks. Standing all-repo requirement - flagged until it lands.
2 findings above for review.
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.
allan
merged commit 7d0e349247 into main2026-09-22 16:38:19 +00:00
allan
deleted branch docs/full-table-search-row-cap2026-09-22 16:38:19 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
hermes
#5 documented the row count next to the table name as "the number of rows the search matched, which can be higher than the number of rows displayed". Measured against a live Viya estate, that is not what a search does.
Searching a 1200-row table for a value present in every row:
For a search, both numbers stop at
DC_MAXOBS_WEBVIEW- the count is the capped count, not the match total. The "count higher than displayed" behaviour belongs to the unsearched view, not to the search. (The 499 came from an off-by-one in the search branch ofviewdata.sas, fixed separately.)The bullet now reads:
Everything else added by #5 held up against the same estate - the case sensitive CONTAINS wording (
SmithfindsSmithson,smithfindsGoldsmith,smithdoes not findSmithson), the exact numeric match, every-column coverage, the filter scoping, the no-data panel text, and the screenshot.Follow-up to #5, which was merged before this correction could be added to it.
Reviewed the full diff at
206d88c(one docs file), verifying the changed row-count claim against the viewer code path (viewdata.sas caps both the search result and the reported count at DC_MAXOBS_WEBVIEW; viewer.component.html:433 renders sasparams NOBS). No CI workflow runs on pull requests in this repo and there is no semantic-release, so no pipeline or release-message concerns apply.docs/dcu-tableviewer.md:24 - the sentence hardcodes the default as fact: "returns the first 500" and "that capped count". DC_MAXOBS_WEBVIEW is configurable (viewdata.sas:179-184 falls back to 500 only when the option is unset), so the text is wrong for any non-default setting. Phrase it against the option - for example "returns only the first DC_MAXOBS_WEBVIEW rows (500 by default), and the row count shown next to the table name is that capped count" - matching the option-reference style of the same line.
repo root - no .pre-commit-config.yaml exists in this repository (and no other gitleaks pre-commit hook), so nothing scans staged content for secrets at commit time. Add .pre-commit-config.yaml with a gitleaks hook pinned to an exact release tag, for example repo: https://github.com/gitleaks/gitleaks, rev: v8.30.1 or the current release, hooks: - id: gitleaks. Standing all-repo requirement - flagged until it lands.
2 findings above for review.