Fun with Azure Moblie App errors

I’ve been pushing my Azure data backend pretty hard the last few weeks.  As Simple PoS has been getting closer to production I’ve been pushing more and more data into it, expecting speed and volume would show any cracks while I continued development.

This has shown me a few things that I didn’t know before and are worth sharing:

1.  Don’t cheat with record duplication.

I had cause to duplicate a record in the database.  For right or wrong at the time I decided that I could get the current record, delete the primary key from it and re-insert it.  On the surface this seems like a safe, future proof way of not having to worry about schema changes.

However I think Azure might be smarter than I expected and seemed to realise that the records were the same anyway (possibly the version ID?)  It didn’t overwrite the data (phew) but it gave very strange and untraceable errors. I’m not 100% sure on why this happened/happens but wise to avoid it.

2.  Errors; catch them early and fix them fast

Due to the offline local cache mode available in Azure Mobile Apps, you might not see a push error right away.  Not until the next push or full sync is made.

But once the push fails, if it doesn’t rectify itself then you start seeing sync errors on all your tables that are updated. This means that you are getting errors with an error count of 0 (yes, really) in tables for no apparent reason.  In hind sight it makes sense as the error is actually somewhere else but the sync can’t succeed in that state.  So it is important that you either catch the very first error, or can reproduce it from fresh, otherwise fault finding can be convoluted by many false negatives.

3.  Don’t treat Offline Data syncs like a real time database.

Async != magic.  It sounds obvious but at some point I had a leftover bit of code from very early on that was calling push asynchronously after a record was updated.  This was happening for every field that was calling update.  On a local (only) DB you can do this.  On a synchronized copy it can present you with real problems as you can update multiple fields on the same record faster than the async push can happen in the background. It isn’t disastrous in effect but in my current Azure Implementation Bug Hunting mode I’m taking the opportunity to get in early and get it right.

I hope that this can help someone else out at some point.

Valley Software