RegContent

Fixing ALTER TYPE / views_valid

After a type change, DQL against a custom type can fail even though the objects are intact. Content Server’s type views in the RDBMS are often stale. Rebuilding them is a last-resort DBA step with the docbase down — not a daily DQL habit.

What views_valid is

Each persistent type has RDBMS views (single-valued and repeating) that DQL is rewritten against. dm_type_s.views_valid is the flag that says those views still match the type definition: 1 means trusted, 0 means rebuild on the next docbase start. ALTER TYPE, attribute add/drop, repeating vs single flips, and hierarchy edits can leave the flag or the views themselves behind. Setting the flag to 0 on the affected type and its supertype is how you ask the server to drop and recreate the views when it comes back up.

Pattern

  1. Stop UI servers (DA, D2, REST, and anything else holding sessions against the docbase).
  2. Stop the docbase.
  3. DBA sets a restore point (flashback or the equivalent for that RDBMS).
  4. On the database, for each affected type and its supertype:
UPDATE dm_type_s SET views_valid = 0 WHERE name = 'custom_subtype';
UPDATE dm_type_s SET views_valid = 0 WHERE name = 'custom_document';
  1. Start the docbase. The server rebuilds the views; views_valid should return to 1.
  2. Confirm the previously failing DQL now works.
  3. Start UI servers.

Use only the type names that actually changed. The placeholders above are a subtype custom_subtype whose parent is custom_document — substitute yours. Do not run this SQL while the docbase is up.

Related