Commit Graph
10 Commits
Author SHA1 Message Date
dc 1a5cea9ebe docs(validations): a date formatted column takes no special missing 2026-09-23 15:38:37 +00:00
dc abf01d6375 docs(validations): the dropdowns support special missings
Both SOFTSELECT and HARDSELECT support them, and the dropdown lists them
alongside the ordinary values (no NaN entries for a numeric column).
2026-09-23 08:37:12 +00:00
dc e7fdb3ab52 docs(validations): primary keys are NOT NULL; HARDSELECT can match a special missing
- a primary key column rejects a blank and a special missing whether or not
  the table carries a constraint or MPE_VALIDATIONS a NOTNULL rule
- HARDSELECT is now checked like any other value: it passes when the
  dropdown list contains the special missing
- HARDSELECT drops out of the 'not supported' list
2026-09-23 08:19:40 +00:00
dc 4d53ced89c docs(validations): document how each rule treats a special missing value
New Special Missing Values section covering NOTNULL, MINVAL/MAXVAL, CASE,
ROUND, the regex rules, the dropdowns and the formula rules, with the
'not supported' set called out.  Behaviour verified against a real SAS
estate and the deployed frontend validator.
2026-09-23 07:50:06 +00:00
dc 99b2a7454e docs(viewer): state the row count rule for the unsearched view too
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.
2026-09-22 16:34:14 +00:00
dc bd30a059ed docs(sas9): unzip the frontend archive into its own folder
frontend.zip now holds the frontend files at their root (dc/dc #147, released in
v7.14.2), so unzipping no longer produces a client/dist folder to navigate into.

Step 2 now says to create the app folder and unzip the archive into it, naming
the file that should end up there. Step 3's URL example matches the folder the
reader created, and the intro line drops "to the root of" - it contradicted the
subfolder instruction directly below it.
2026-09-22 16:28:10 +00:00
dc 206d88c6a9 docs(viewer): correct the full table search row count claim
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.
2026-09-17 11:43:23 +00:00
dc 85f200c724 docs(viewer): correct the character search example to match the code
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`.
2026-09-16 23:42:37 +00:00
dc 4a53499055 docs(viewer): show the matching column in the full table search screenshot
The screenshot showed the siphonophore search returning 3 rows, but the
NOTES column - the only column the value appears in - was clipped off the
right edge, so the image did not show why those rows matched.

Re-captured at 1920x900 (all nine columns on screen, no clipping) from the
mocked instance, with the capture gated on an assertion that the matched
cell is inside the grid viewport.
2026-09-16 23:38:14 +00:00
dc d95f440c4f docs(viewer): document full table search semantics with a screenshot
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.
2026-09-16 00:52:12 +00:00