“Perfect is the enemy of good”, a smart person said once. Another one said: “If it works, don’t mess with it.”
So, I messed with it. I was trying to make it perfect.
Over past couple of weeks, you might have experienced downtimes, or even errors such as 403 Access Forbidden or similar here on my blog. The reason is—I was trying to make it perfect, and now I see that good might have been good enough.
As a part of my blog reviving efforts, I’ve tried improving the performance. The blog was awfully slow, so I offloaded the static content to CDN and installed the W3 Total Cache plugin to help me improve my speed. Which it did. For a while.
Then it started behaving funny, and was intermittently and unpredictably throwing errors at my visitors, for which I sincerely apologize. You don’t deserve to be thrown errors at. Honestly.
So, I’ve switched the page caching off for the time being, while I try to sort it out. In the meanwhile, I ask my fellow bloggers, if you are using WordPress and W3 Total Cache, and have experienced something similar—please help.
If you try exposing Page 5 Currencies as a Web service in Microsoft Dynamics NAV 2009, and then consuming this web service through a .NET application, you are almost guaranteed to encounter some unhelpful and generic XML errors that give you absolutely no clue about what exactly, where and why, went wrong.
Here’s an example of the error:
There is an error in XML document (1, 3634).
The error took me a while to debug and pinpoint the source, but in the end I managed to find a neat solution which I find worth sharing here, just in case somebody out there is scratching their had over it.
Don’t you just love when users come up with new feature ideas at a microprocessor clock rate. Even before you finish developing one, five new requests pop up. This is a disease, and it’s called featuritis!
They say the only constant is change. I’d say that the only other constant is error. We humans tend to err. Give a repeatable task to a human, and they’ll mess it up every once in a while. Some call it the human factor.
One of the many repeatable tasks in Microsoft Dynamics NAV is setting up items. If you remember my rant about mandatory fields, and how I said they were baaad, there might be an even more baaad kind of fields: the default value fields. Because the system simply inserts a value into these fields without asking for your say, and if anything is easy, it’s only so easy to overlook these. Yep, you have a chance to voice your oppinion on these, but having got to hurry for a cup of coffe with Mary from accounting, admit it, you’re gonna leave that default FIFOcosting method for an item every once in a while, even though it should really have been Average. Then you’ll start posting. Then your phone rings and starts screaming at you about a moron who screwed up items again.
There is only one way to abort a user action in Microsoft Dynamics NAV: by using the ERROR function. This function essentially stops the execution of all code, and prevents completion of the user action, whatever such action might be.
One of typical situations where ERROR is used to prevent user action is during validation of a new value in a field. A typical concrete example of this behavior is entering the Customer No. value in the Sell-to Customer No. field on the sales order form. When users enters a value, the system goes through a series of checks, called validation, which in the end may result in the system rejecting this value. Obviously, the only way for the system to reject a value entered by the user is, yes you’ve got it, by calling the ERROR function, which returns the system to the last committed state before the error.