Page History

...

When a user types a value into a text field (which is bound to a specific column of the database table) and clicks out, the Servoy Application Server issues a SQL update command to the database to modify the selected record. The resulting change is also broadcast|display/DOCS/Data+Broadcasting|||||||||||||||||||||||||\ to all connected clients.

...

The fundamental unit of data binding in both the GUI and the API is the Servoy Foundset|display/DOCS/Foundsets+Concepts|||||||||||||||||||||||||\ object.

...

• External changes were made using the Raw SQL Plugin to update a specific database table. Although, initiated from Servoy client session, this (This plugin bypasses the Data Binding layer and will not be reflected in the client cache. 
• External changes are known to have been made on a specified table because a 3rd-party application another application or service was invoked from Servoy client session.
• External changes may have been made to a specific table by another application, but it is not known for sure. In this situation it may be ideal to periodically update the client caches using a Batch Processor, which is a server-side client session that can perform automated, scheduled operations.

Notify Data Change

This approach essentially forces a Data Broadcast Event to all clients. Clients are informed of changes to specific records, just as if those records were modified from within the Servoy environment. This approach is more granular than updating the entire cache for a specific table and should also yield better performance. This approach is ideal to use when:

• External changes were made using the [Raw SQL Plugin|DOCS:rawSQL] to update a specific table by another application. In this situation it may be ideal to periodically update the client caches using a Batch Processor, which is a server-side client session that can perform automated, scheduled operations.

Notify Data Change

• specific database records and the primary keys are known. 
  * Another application or service was invoked from Servoy client session affecting change to specific records who's primary keys are known.
  

  Tip
  This approach can also be used to allow Servoy's cache to be updated proactively from another application via a simple web service call. Any method can be exposed as a RESTful web service. Therefore, it is simple to create service that allows another application to inform Servoy of data changes. For more information see th documentation on Servoy's RESTful Web Services Plugin .

  
  

  Note
  For more information, see the notifyDataChange method in the programming reference guide.

  
  
  Refresh Record From Database
  
  h4. Data Transactions in Servoy
  
  Data manipulations in Servoy happen inside an in-memory transaction. When a record is created or modified, either by user action or by developer, nothing is committed to the database immediately. The Servoy Client tracks all newly-created and modified records, including which columns have changed, their former and latter values. As records are added or modified, the amount of information stored in the In-Memory transaction accrue until they are committed or rolled back. The duration of this In-Memory transaction can be short or long depending on the client's configurable Auto Save setting.
  
  h5. Auto Save: ON
  
  By default, every Servoy client is started with the Auto Save setting initialized to on/true. This means that the In-Memory transaction is typically very short as changes are committed automatically as the user navigates the client session. Specific actions like clicking in a form's area, navigating to a different form, clicking a button, etc. all trigger a save event. Auto Save is ideal for situations where the user is intended to be able to make edits freely.
  
  
  h5. Auto Save: OFF
  
  The developer may optionally set the Auto Save setting to off/false. This means that the length of the In-Memory transaction is controlled by the developer. As changes accrue, they are never committed until the developer programmatically invokes a save event. It is ideal to disable Auto Save for scenarios where the user is intended to perform edits in a controlled situation where a group of edits may be saved or rolled back all together.
  
  The Auto Save setting can be programmatically changed throughout the duration of the client session to accommodate different modes for different editing scenarios.
  
  h5. The Anatomy of the In-Memory Transaction
  
  Servoy provides a robust data API, giving the developer full access to the In-Memory transaction, which consists of a listing of all record objects that were added or modified. For each of these record objects, there is a listing of every column whose value was changed. For every modified column, there is a reference to the value before and after the edit. The transaction API also allows developers to distinguish between records that are newly-created and do not yet exist in the database, versus records that already exist in the database, but have outstanding edits.
  
  
  h5. Saving Data Changes
  
  A developer can programmatically issue a save event, causing the contents of the In-Memory transaction to be automatically translated into instructions to insert/update database tables. A developer can optionally invoke a save event for a specific record only, leaving the rest of the transaction unaffected.
  
  If for some reason one or more records were unable to be saved (i.e. due to a back-end database violation, etc.), the transaction will also keep track of Failed Records and their associated errors.
  
  
  h5. Rolling Back Data Changes
  
  A developer can programmatically issue a command to rollback the contents of the entire In-Memory transaction, causing newly created records to be removed and modified records to be reverted to their state prior to the start of the In-Memory transaction. The developer can optionally choose to rollback changes for a specific record, leaving the rest of the transaction unaffected.
  
  h5. What about Deleting Records?
  
  It is important to note that record deletes are not part of the In-Memory transaction. When a record is deleted, the instructions are sent to the database immediately and the delete cannot be rolled back.
  
  
  
  h4. The Servoy Foundset
  
  
  The Servoy Foundset is a developer's window into Servoy's Data Binding layer. A single foundset always maps to a single database table and is responsible for reading from and writing to that table. From the user interface, a foundset controls which records are loaded and displayed, as well as how records are created, edited and deleted. From the developer's perspective, a foundset is a programmable object with specific behaviors and run-time properties that provide a high-level abstraction to facilitate low-level data operations.
  
  
  
  h5. Forms Bound to a Foundset
  
  A Servoy Form is typically bound to a single database table and the form will always contain a single Foundset object which is bound to the same table. Much of the action in the user interface, such as a user editing data fields, directly affects the form's foundset. Conversely, actions taken on the foundset, such as programmatically editing data, is immediately reflected in the form.
  

  Note
  While a form is always bound to a foundset, a foundset may be used by 0 or more forms. Foundsets can be created and used by a programmer to accomplish many tasks.

  
  
  Often, there can be several different forms which are bound to the same table. In most cases the forms will share the same foundset and thus provide a unified view. For example, imagine a form showing a list of customer records, where clicking on one of the records switches to another form showing a detailed view of only the selected record. The forms will automatically stay in sync and there is no need to coerce the forms to show the same record. Exceptions to this behavior include scenarios where forms are shown through different Relations, or have been explicitly marked to use a separate foundset.
  

  Gliffy Diagram
  name Shared Foundsets

  
  
  
  
  h5. Loading Records
  
  One of the primary jobs of a Foundset is to load records from the table to which it is bound. A Foundset object is always based on an underlying SQL query, which may change often during the lifetime of the Foundset. However the query will always take the form of selecting the Primary Key columns from the table and will also always include an Order By clause, which in its simplest form will sort the results based on the Primary Key column(s).

  Code Block
  lang sql title Foundset Loading borderStyle solid
  SELECT customerid FROM customers ORDER BY customerid ASC

  
  After retrieving the results for Primary Key data, the Foundset will issue subsequent SQL queries to load the matching record data in smaller, optimized blocks. This query happens automatically in an on-demand fashion to satisfy the Foundset's scrollable interface.

  Code Block
  lang sql title Example: Record loading query borderStyle solid
  SELECT * FROM customers WHERE customerid IN (?,?,?,?,?,?,?,?) ORDER BY customerid ASC

  
  
  h5. Sorting
  
  All foundsets contain a sorting definition that determines the order in which records are loaded and displayed. Sorting is always expressed in the ORDER BY clause of a foundset's query and thus handled by the database.
  
  A foundset's sorting definition is encapsulated in a String property, which can be programmatically read using the getCurrentSort method, and written using the sort method. 
  
  Parameters for this property include an ordered list of one or more data providers, each of which having a sort direction, either ascending or descending. The string takes a form such that each data provider and its sort direction are separated by white space. The direction is abbreviated either asc or desc. Multiple data providers are separated by commas.
  
  Example: Sort String Format
  

  Code Block
  'column1 asc, column2 desc' // Sort on column1 ascending, then column2 desceding

  
  The order of the data providers determines their relative priority when sorting, such that when two records contain the same value for a higher priority data provider, the sorting will be deferred the next lowest priority data provider.
  
  Example: The following sort string will sort, first on last name, and second on first name.
  

  Code Block
  foundset.sort('last_name asc, first_name asc');

  
  The result is that all records are sorted by last name. But in the case where the last names are the same, then the first name is used.
  || last_name

...

• || first_name ||

  Sloan	Zachary
  Smith	Jane
  Smith	Jon
  Snead	Aaron

  Available Data Provider Types

The following data provider types may be used as sort criteria:

...