So basically you are asking for inter process communication between the database engine and your app.

For a "push" approach your idea with a trigger-based seems reasonable, as only triggers can immediately react upon DML statements like an UPDATE. If updates to the accordings tables are infrequent, you might trigger a push notification for each update, if they are more common, you will probably use some kind of delay to prevent too frequent notifications. Using an database event (CREATE EVENT...) that runs on its own connection and may "wait a while" before doing the push notification may help here without delaying the actual UPDATEs.

• For version 17, I suggest to use a semaphore with a "producer-consumer model", i.e. the according trigger would call NOTIFY SEMAPHORE as "push" notification. The app itself would need a separate database connection that "waits" on the according semaphore. When the semaphore is notified, the app can refresh its data.
  SQL Anywhere 17 offers also mutexes, which might also do the trick.

• For earlier versions, you might use OS IPC facilities with the help of external functions. We have done this with Win32 named events: When there are UPDATES the database engine would set an event with the help of an external C function calling the Win32 SetEvent API, and the app would use a Win32 wait method like WaitForSingleObject() to get notified on the event.

Of course you could also use a "polling" approach by making the app regularly query the database state. Besides using your own "state table", you could also provide the "state" via an (immediately or manually) refreshed materialized view - the database would not necessarily require triggers to "set a state" but would do this autmatically by refreshing a view. And the app could check via SYSVIEW.mv_last_refreshed_at (or mv_last_refreshed_at_utc) whether the contents has changed.