100% found this document useful (1 vote)
282 views

Simphony Update Functions

The document discusses several functions for updating and refreshing the database in Simphony: 1. Update Database requests configuration changes from the central database and waits for the process to finish before allowing further actions. 2. Refresh Database requests configuration changes from the central database and runs the process in the background without waiting. 3. Refresh Database Live also requests configuration changes from the central database but waits for the process to finish like Update Database. 4. Reload Workstation Database reloads the local database. 5. Redraw Page Content clears and redraws the current page and all other pages with any new content.

Uploaded by

md_ibarra
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
100% found this document useful (1 vote)
282 views

Simphony Update Functions

The document discusses several functions for updating and refreshing the database in Simphony: 1. Update Database requests configuration changes from the central database and waits for the process to finish before allowing further actions. 2. Refresh Database requests configuration changes from the central database and runs the process in the background without waiting. 3. Refresh Database Live also requests configuration changes from the central database but waits for the process to finish like Update Database. 4. Reload Workstation Database reloads the local database. 5. Redraw Page Content clears and redraws the current page and all other pages with any new content.

Uploaded by

md_ibarra
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

Simphony update functions

Update Database
This function will cause Ops start a foreground job that requests any configuration data that has been
changed from the central database since its last database update. Ops will wait for the process to finish
before the user can take another action.

Refresh Database
This function will cause Ops start a background job that requests any configuration data that has been
changed from the central database since its last database update.

Refresh Database Live


This function will cause Ops start a foreground job that requests any configuration data that has been
changed from the central database since its last database update. Ops will wait for the process to finish
before the user can take another action.

Reload Workstation Database


When this key is pressed, the workstation will reload the local database.

Redraw Page Content


After an operator presses this button the current page and all other pages will be 'flushed' and redrawn with
any newly added content.

I will start with a brief discussion of the syncing architecture. Whenever a change is made to the
enterprise database (either through EMC, Import, or some other mechanism), a row is added to a
table which tracks changes, and a row is updated in another table which tracks when each table
was last changed for a particular level in the hierarchy (zone, enterprise, property, etc.). This
second table is cached in memory by the application server, and refreshed every five minutes
(hardcoded).

The client database (could be DataStore, CheckPostingDB, or KDS) periodically asks the
application server “Do you have anything new for me?” How often the client database does this is
configured in Property Parameters, and can be overridden on the Workstation record. The server
will consult the cached list to see if any tables have a newer change time for the requested
hierarchy levels. If so, it will use the change tracking table to put together a list of changes to
send back to the client. The client will then apply that list of changes to the local database.

Another scheduled job in the client periodically wakes up while the client is idle (i.e. not in a
transaction) to see if there have been any changes to the local database. If there have been,
these changes are used to update the in-memory copy of the database that the client actually
uses for operations.

With that out of the way, we turn to the commands in question.


- Reload Database is by far the most intensive of the three. It drops all of the data out of the
local definition tables (i.e. menu items, discounts, etc. but not checks or totals). It then
requests changes from the server, which in this case will cause all the data to be sent back
to repopulate the tables. Finally, it updates the in-memory copy of the database.
1
- Refresh Database signals the scheduled job which updates the in-memory copy to run,
then returns. Refresh Database Live does the same thing, but waits until the update
operation is complete.
- Update Database is our newest command. It sends a message to the application server
requesting the latest changes, but passes a flag indicating it should bypass the server
cache to make sure it gets all changes, including changes that have not yet been read into
the five minute cache. It then applies those changes to the local database and updates the
in-memory copy. It is the most efficient way of getting changes downloaded to the client in
a timely manner.
- Redraw Page Content gets rid of the page cache that we created when a page is first
accessed (to speed page display and navigation/tab switching in ops) and creates a new
cache with the newest information in the database

You might also like