In a traditionally versioned geodatabase, edits are not applied directly to the business (base) table. Instead, they are stored in associated delta tables: the adds (A) table and the deletes (D) table. When a user or application views a version, ArcGIS constructs the representation by combining data from the base table with the changes recorded in the delta tables.

A direct SQL UPDATE command on the base table bypasses this versioning mechanism. It only modifies rows in the base table. Consequently, any features that have been previously edited within a version (and thus have entries in the delta tables) will not reflect the changes made by the direct SQL command, as the information in the delta tables takes precedence. This results in an apparently incomplete update.

A. Nonversioned feature class that is partitioned: Partitioning is a database-level optimization. A standard SQL UPDATE command is handled transparently by the DBMS and would correctly update all specified rows across all partitions.

C. Archiving enabled on the feature class: Archiving creates a history of edits in a separate archive table. A direct SQL update on the base table would successfully modify the data but would bypass the triggers that populate the history, leading to data inconsistency, not an incomplete update of the current feature values.

1. Esri ArcGIS Pro Documentation, "How traditional versioning works": This document explains the architecture of traditional versioning, detailing the role of the business table, adds table (A), and deletes table (D). It states, "When you edit or delete a record in the business table in a version, rows are added to the A and D tables. The original record in the business table is not removed until the database is compressed." This underpins why edits to the base table alone are insufficient.

2. Esri ArcGIS Pro Documentation, "SQL access to geodatabase data": In the section on versioned data, this source explicitly warns against direct modification of the base table. It clarifies that to edit versioned data with SQL, one must edit a versioned view, not the base table, because direct edits to the base table are not reflected in the delta tables and will not be correctly accessed by ArcGIS.

3. Esri ArcGIS Pro Documentation, "Geodatabase archiving": This document describes how archiving works by using database triggers to copy the original state of a modified feature into a history table. A direct SQL update would bypass these triggers, but the update on the business table itself would be complete, which contradicts the scenario in the question.