​

Troubleshooting and limitations

​

Local data

Table data is downloaded to the device for local use. Do not use table-list visibility as a data-protection mechanism.

---

​

Stale data after a failed refresh

A failed refresh can leave the last successfully downloaded data available locally. Seeing rows in the app therefore does not necessarily mean those rows were returned by the most recent source sync. When data appears outdated, verify the sync result before treating the local copy as current.

---

​

Large tables

Large tables:

• take longer to download;
• consume more device storage;
• are transferred in pages rather than as one unlimited response.

Only request fields the app actually requires.

---

​

Row identity

Downloaded rows depend on unique, stable @row.id values. Missing or duplicate row IDs can result in rows overwriting one another in local storage. Id cannot substitute for a missing @row.id.

---

​

Local value types

Local consumers generally read downloaded values as text. Do not depend on a numeric or Boolean source value retaining its original source type when used in a local lookup or comparison.

---

​

Removing table configuration

Removing a table setup record does not, by itself, guarantee that previously downloaded reference data will be cleaned up locally. Validate cleanup behaviour separately when removing a table.

---

​

displayColumns

displayColumns does not currently control which fields appear on the table screen.

---

​

view

view does not currently select a source-database view.

---

​

Column order

The order of requestColumns is the request order. It is not a guaranteed table-screen column order.

---

​

hideColumns

A role-specific hideColumns entry affects the fields downloaded for that role. It is not merely a visual hiding mechanism.

---