Zumero


Upgrading to ZSS 1.4

18 June 2014

ZSS 1.4 is a recommended upgrade for all users. To ensure a seamless upgrade on the server side, and client-side data safety, please note the following:

Replace client-side databases which use ON DELETE CASCADE

ON DELETE CASCADE is used to delete dependent data automatically when its “parent” data is deleted — for example, Line Items in an Order might be deleted when the Order is deleted.

CREATE TABLE orders (
    orderid INT IDENTITY PRIMARY KEY,
    custid INT REFERENCES customers(customerid)
);

CREATE TABLE lineitems (
    lineid INT IDENTITY PRIMARY KEY,
    productid INT REFERENCES products(productid)
    quantity INT,
    orderid INT REFERENCES orders(orderid) ON DELETE CASCADE
);

ZSS 1.4 fixes a bug where, if ON DELETE CASCADE was used in a schema, client-side data could become corrupt. Once this corruption occurs, the client can no longer pull data from the server. No server-side data is harmed or lost.

ZSS 1.4 prevents this problem, but cannot repair existing corruption. If your existing client apps sync tables which include ON DELETE CASCADE provisions, the simplest way to replace your client-side databases is to:

  1. Update your app to use the ZSS 1.4 Client SDK
  2. Modify your app to use either a different name, or a different folder, for the locally-synced database.

For example, if you previously synced a pendingorders DBFile as:

NSString *dbpath = @"/somefolder/pendingorders.db";

FMDatabase *db = [FMDatabase databaseWithPath:dbpath];

dispatch_async(
    dispatch_get_global_queue(
        DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), 
    ^{
    BOOL ok = [ZumeroSync Sync:dbpath
                     cipherKey:nil
                     serverUrl:@"https://serv.er"
                        remote:@"pendingorders"
                    authScheme:nil
                          user:nil
                      password:nil
                         error:&err];
});

[db open];

The following will use a new, clean local database:

NSString *dbpath = @"/somefolder/pendingordersV2.db";
// or @"/someotherfolder/pendingorders.db"
// or @"/somefolder/pendingorders.db2"
// etc.

// nothing else changes

If you are pre-loading a baseline copy of the SQLite database in your app’s distribution, be sure to rename that as well.

Ensure VIEW SERVER STATE permissions

Both ZSS Manager and ZSS Server require VIEW SERVER STATE permission on your SQL Server Databases to function properly. This is not a new requirement, but prior to ZSS 1.4, the server was more likely to “get away” with insufficient permissions.

ZSS Server 1.4 needs that permission routinely; servers which once appeared to be properly configured may now fail. No data will be lost, but your clients will be unable to sync until server permissions are fixed.

VIEW SERVER STATE can be added via a SQL Query (run with admin permissions):

GRANT VIEW SERVER STATE TO yourLogin

or via SQL Server Management Studio:

  1. Right-click the server
  2. Properties
  3. Permissions
  4. Select the user(s) gaining permission
  5. Check “Grant” in the “View server state” row
  6. OK