SQL Azure is a very interesting service. It’s as interesting as it is misunderstood both in terms of how exactly it works, and what it’s intended to be used for.
First of all, it’s not really the same thing as SQL Server that you install on your box, virtual or physical. It certainly provides the same functionality, and from functional perspective most of things you can do with SQL Server, you can do with SQL Azure. But it behaves in so many different ways that you can’t truly compare them side by side.
Another thing is what SQL Azure was designed for. It’s designed for massive cloud workloads where concurrency is more important than sheer speed. And in that respect it is just brilliant. However, to get most out of it, you have to write and optimize your database access code specifically to take advantage of its features and behavior, otherwise, you simply get performance that can be qualified as mediocre at best.
What happens when you put NAV on SQL Azure? Well, that’s something that you certainly can do – Microsoft does it as well. The thing is – it works. It leaves a bit to be desired if you intend to run heavy processing, but my firm conviction – having tested it and having gone medieval on it with my tests.
Let’s take a look.
Continue reading NAV performance part 4: SQL Azure
Ancient wisdom goes that you cannot have more than one write transaction going on at the same time in a single session in NAV.
This is absolutely true, in and out.
Some features, like Activity Log, will leave you wanting to be able to write to the database outside of the normally running transaction.
Wouldn’t it just be beautiful if you could:
- Write to the database, and then persist the change to the database even if an error happens during the transaction? (without cough! TryFunction, cough! cough!);
- Not cause any locks to remain at the target table for any longer than it takes to do the write itself, without having to call COMMIT on your “regular” transaction; and
- Not use temporary tables, because a system error (however unlikely) could cause the data to not be persisted if crash happens before temporary table is flushed to the physical one.
Well, in fact, you can do this.
Continue reading Out-of-transaction database writes
Today at NAV TechDays 2015 in Antwerp, I attended a presentation by Nikola Kukrika, Ciprian Iordache, and Gary Winter, at which Ciprian presented a new design pattern based on a new feature in NAV 2016: Activity Log.
In a nutshell, this new feature, and thus the design pattern, aim at helping trace issues and facilitate troubleshooting by leaving information in the database about what was done, by whom, if it failed, and if it did, why.
All pretty and nice, but – as Ciprian pointed out – there is a bad aspect about it: when an error happens, and everything is rolled back – the activity entry is rolled back together with everything else. Nikola later explained how this could be solved through writing into temporary tables, but this either requires redesign by Microsoft or special coding techniques by you.
However, there is a bigger caveat than this. Non-persisting data in case of errors is a problem, but the bigger problem lies elsewhere. Let me explain that bigger problem here, and then give a silver-bullet solution to solve it all.
Continue reading Activity Log or Activity Lock pattern?
One of the choices a customer interested in Microsoft Dynamics NAV must definitely make is the choice of the database platform. With NAV, there are two possible options: so called native database server, which is not really officially called that (the official name is Microsoft Dynamics™ NAV Database Server), and Microsoft SQL Server.
Continue reading Native vs. SQL: The Evolution