Working with Briefcases

bagageOne very useful feature of Data Abstract is Briefcase support. The Data Abstract briefcase provides local persistent storage. Simply store the data in a local briefcase file on the client file system, and the data can be reloaded without needing to request it again from the server.

Some common use cases:

  • Use briefcase for saving client data including uncommitted changes between restarts of your application.
  • Store some quite constant dictionary tables into briefcase and load them during application start and thus avoid having to reload the same data from the server.
  • Request only the changed records for some huge table from the server side and then merge the delta with the client table loaded from the local briefcase.
  • Use briefcases if you don’t have a persistent connection to your server and the user needs to be able to work in offline mode. Use Data Abstract’s robust conflict resolution to post the changes later.

In addition, a set of custom, application-specific string properties can be stored alongside the data. This can be useful, for example, for storing the version number of the data format to ensure newer versions of your application can reload the data correctly, if data formats change over time. (It is not recommended though to use this space for general application settings that are not directly related to the data.)

The main advantage of using a briefcase instead of some embedded database (f.e. SQLite.NET) to cache user data or to implement offline mode is that a briefcase stores not only user data but also its state (i.e. deleted, updated or inserted data rows). This greatly simplifies further synchronization with a Data Abstract-based server.

You can learn more about working with offline briefcases:

And more in the official RemObjects Documentation Wiki.