The bug with which I started this series is nothing critical. It manifests rarely, you can easily work around it. It’s in the “so what” category.
But the one I’ll talk about today is a tough beast, with not-so-easy workarounds that cause as much headache as the bug itself.
So, here comes bug #2: setting a date to 0D.
If something, Stratus has taught me how buggy the implementation of Web services in Microsoft Dynamics NAV is. Let me be clear from the onset: Web services are a great functionality in NAV, one of the best additions (together with .NET interop) to NAV stack in a long while. But it’s buggy.
Being buggy doesn’t mean it doesn’t work. It only means you need to twist and bend your code to achieve things which you would expect to work out of the box. During development of Stratus, we had to make a series of workarounds in Web services to achieve simple goals, and I decided to share those bugs (and workarounds) with you, to help you be more productive in your Web services based projects.
So, here we go for bug #1: lowercase codes in primary key.
It all started with Waldo and his Dynamics NAV 2009 R2 is not a “normal” release … beware! post two weeks ago. Waldo did not complain (much 
), he explained what R2 is and what it isn’t, and it turns out that it isn’t many of the things people hoped it was.
Then Luc followed with his Dynamics NAV 2009 R2 is … post, in which he again says NAV 2009 R2 is not normal.
I’m sorry to say, but I am definitely joining this “not normal” party, ‘cause there is something strange going on with NAV, and I believe there will soon be either a SP(how does NAV 2009 R2 SP1 sounds?), or a series of hotfixes.
A bug or a feature? Sometimes it’s hard to tell for sure.
Web services are a fantastic tool in NAV, however, they do not always behave exactly as you would expect them to. There is one particularly annoying behavior, which just after you get used to it starts getting even stranger.
So, setting any numeric value during the Create method call on any page web service will have no effect, and the only way to set a value in a numeric field would be through a subsequent call to Update method.
Design is one of a kind. Other phases in Sure Step are understood and accepted as good and necessary. But design, do we really do that? Is it really necessary? Who’s going to pay for it? Does the customer really need all those documents? Instead of writing documents, you could have it developed in the same, or less time. And so on and so forth.
As a matter of fact, if you asked me to pick one single most important phase in a Sure Step project, then it’s the design. No second thoughts here, whatsoever.
Here I list the ten most important reasons that I believe make design absolutely indispensable.