A SQL View stores a query definition rather than another copy of application records. A native KAS Table View can read an existing View through its ordinary dbtable/query configuration.
Arrays are the newer full, extensible configuration and are preferred for new definitions. Strings remain compatible legacy shorthand/quick syntax. Option keys are specific to each native field type.
The names below are placeholders for a View and columns that already exist in the owning application's schema. Inspect its definition and use the real stable key:
$dbtable = 'EXISTING_REPORT_VIEW';
$idfield = 'ROW_ID';
$td_titles = ['LABEL', 'AMOUNT'];
$td_fields = [
['type' => 'text', 'col' => 'LABEL', 'options' => []],
['type' => 'price', 'col' => 'AMOUNT', 'sign' => '$']
];
$query = 'SELECT ROW_ID,LABEL,AMOUNT FROM EXISTING_REPORT_VIEW %%WHERE%% ORDER BY ROW_ID';
include('core/table_view.php');Include the stable key even when it is not displayed. Keep routing, account authorization, search/category predicates, pagination and export native. Test both count reconstruction and displayed rows with the actual query.
Joined/aggregate reporting does not authorize editing or deleting source records. A View is not an application authorization boundary: inspect its security context and database grants, and authorize its owning KAS page.
Creating/replacing a View requires appropriate database privileges; inspecting its definition requires SELECT/SHOW VIEW. Recheck Views after base-schema changes, including empty data and numeric types. Preserve exact numeric calculations and separate currencies. See MariaDB's View documentation for database semantics.