Updating immediately?
Not always!

If I make a change, is it visible everywhere immediately?

MCe is very good about handling your data when you are offline or flaky internet.

Very good means in part:

  • We cache data to avoid hitting the server too much
  • We cache data to avoid passing too much data back and forth
  • We anticipate what data you will need and get it
  • We let you tell us what data you will need and keep it up to date, this lets you avoid issues where our generic algorithms don't understand your data and use cases well enough. This typically can only be done by an administrator, although your administrator might have granted you access to setting it up, anything your administrator(s) set up will be available for you.
  • It is fast; in almost everything you do, it faster than 'normal' applications because we don't have to go back to the server for every little detail.
  • We optimize for normal use case.
  • Where possible, we also optimize for unusual use cases.
  • But we don't optimize to 'pass a test' that isn't a normal situation when really working with it.
  • While it might sound contradictory, we also try to download the least amount of data possible
  • On demand data we try to grab "as needed" – because you cannot realistically have the whole server database on your device, and keeping it up to date would require a huge amount of space, bandwidth and server resources
  • Pictures tend to be downloaded as needed, with the browser handling the caching of them

We make strategic choices about when changes on your local system update on your local system in other places.

In most cases, we are able to do it efficiently without noticeably slowing your device down. But in other cases, at least with technology speeds circa 2022, the performance hit of doing certain checks all the time would be too high for the very rare time that it would give you a benefit.

A common example: If you update something with a new photo, then that same item is used immediately in a picker – you will not get the new photo until the next sync has run.

If you really want it to work immediately, do a sync after you add the new photo. But realistically, this is something you would do when testing the system, not something you would do in normal operations. After all, you just added the photo to, for example a part, you shouldn't need it to choose that same item to add to a work order.

For another user to see the data, it first has to get to the server, and then to their device. We discuss both of those below.

When is my data saved to the server?

First you have to have at least a flakey connection. If you have no connection, we can't send your changes to the server.

There is a lot of logic to optimize this, based on 20 years expertise and experience. It also changes from release to release as we find or design improvements.

If you want to force all the changes – click on the sync button for force sync'ing "now".

As you are making changes, we wait a few minutes typically before saving the changes, this gives you time to edit them without them updating the permanent log

We save in transaction order

Circular reference

Imagine that you create an Asset, then you create a classification, then you add the classification to the asset, then you add the asset to the classification.

If you did that all before we sync'd and we saved 'the asset' it would fail – the classification doesn't exist. If we saved 'the classification' it would fail – the asset doesn't exist.

So we instead save each change in the order you did them. You created the asset (a transaction or multiple) you create the classification (another transaction or multiple) you attach the classification.

All or none, except when that would be bad.

Imagine a simple pair of changes: You attach a photo to a work order. Then you close it. Now imagine you have a report that automatically is generated and emailed to your customer when the work order completes. Or maybe it is generated manually. Realize that, if the "close" change was saved, the user could put their device in a state where we can't save the image. Lots of ways: Get on an airplane, close the browser, turn the device off, and on devices short of memory, simply answering the phone and having their iPhone swap the browser out of memory. In all these cases, it might literally be days before the image gets sent to the server. We would accept that properly – but any processes you ran, such as a report, would be too late to fix. So … we simply don't do that.

The code that does the sync'ing has no real way of knowing whether there is something "important" that may happen that requires the photo that could happen before the photo arrives.

This means we have to save the whole image before we can accept the "close work order" change. And good news, that is what we do. But we have a little bit of an optimization (actually it is a huge optimization.) you will remember above we said that we "waiting a few minutes typically before saving the changes". Well, here is one of the reasons we use the politicians style weasel word "typically":

A picture is worth 1,000 words, or is it a 1,000,000?

In computers, it is often closer that a picture takes the bandwidth of a million words. That means that we can save a lot of changes in text in the same amount of time that we can save one image.

But remember that we also said we wait a few minutes before sending something to the server so you can change your mind.

So, when you take a picture, as soon as you have a connection, we try to send it (if we aren't sending too many others already.) The hope is, that by the time we KNOW we want the photo, it is already on the server, and so it takes almost no time, like a text change, to commit it.

Now, we put it in a temporary cache on the server. When the "yes I want it" comes – it is moved from the temporary to the permanent location. If you change your mind, it is deleted from the temporary cache. This allows things to run through with the least possible delay.

When do I get changes FROM the server?

These be mostly changes other people sent to the server since you last got your data. In some rare cases, it is changes that you sent such as the picker examples above.

If you are working on something, we check frequently, sometimes as often as every minute. So for example, if you are working on an inventory count, we are checking for changes others are making every minute or so.

If you are not working something, we check less frequently, typically every 30 minutes.

If you click the sync button, it will force everything to sync both to and from the server.

When should I sync manually?

There are a few special cases where you will want to manually force a sync.

  • If you are about to leave for a week and not have internet access, you need to sync each database you need up to date before you lose your network connection.
  • In the rare case that you know there is a change that someone else has done in the last 29 minutes that you need to get 'now', you can force a sync 'now'.
  • or you just want to be sure you are completely up to date, you can force a sync 'now' so you can watch the status of each of the portions of the sync to see if they are complete.