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


In the Lab: Simple PoS

I have been quiet on here for the past couple of months.  But there’s been much activity behind the scenes.

We are preparing to release our next, and biggest, app to date; Simple PoS.

Our target is a late June 2017 public release, so watch this space.  Now that we are close I feel it is appropriate to start giving peaks into the Valley Software lab.

Simple PoS is an Azure Hosted, always available Point of Sale system aimed at micro and small businesses for Windows 10 and Windows 10 Mobile.

Everything in Simple PoS is built with simplicity in mind.  That goes from the interface to management and even to the pricing model.

You can install Simple PoS, sign in with your Microsoft account (which you already have for the store, so no sign up with Valley Software or other parties) and be up and running in under 60 seconds, no commitment or purchase required.

You have 100 transaction trial period, which should be plenty to see how Simple PoS can work for you.  Again, no sign up or commitment.

Then, when you decide to purchase it is by monthly subscription, with no outright software purchase.  Even this subscription is purchased through the Microsoft App Store using In App Purchase.  It’s as easy as purchasing upgrades in a store game.

Being designed from the ground up for Windows Universal you can install and use Simple PoS on up to 3 Windows 10, Windows S and Windows 10 Mobile devices at once with just one license.

Simple PoS.  Simple, safe, available anywhere.

Valley Software.

Voyer; 2 months of updates.