Help is on the way

I finally got chance to finish reading through the Microsoft Dynamics NAV Statement of Direction I blogged about last week in my post on the NAV 2009 service pack 1. There’s a lot of marketing waffle in there, as you would expect, but also quite a few interesting things to look forward to.

The online help in NAV is something I am quite passionate about, and have looked forward to the day when help can be easily modified. This section from the statement of direction caught my eye:

“We will reduce the cost to implement custom Help by eliminating CHMs as the delivery format for Help. We will provide mechanisms for partners to extend Microsoft Dynamics NAV Help at a low cost, by integrating Help authoring into the Microsoft Dynamics NAV development process, and by using Microsoft Word, HTML, and Microsoft SharePoint. We will make it easy to extend Help with content on a partner Website.”

Now that sounds pretty exciting. Editing help in Word? Deploying via SharePoint? Cool!

The Amazing World of Blogging

I got a comment on a blog post tonight. That's pretty rare. But what's truly amazing is that the blog post was made in April 2007 -- over 2 years ago! It was my third ever blog post.

I guess this just emphasises that you never know who is reading what you write. Thank you to that annonymous commenter from Poland that decided to share their thoughts on that post. It really made my day.

The blog post was http://gaspodethewonderdog.blogspot.com/2007/04/goodnight-kiwi.html

NAV 2009 Performance Guide is here

The long awaited NAV 2009 Performance Guide is here. You can download it from the mbs.microsot.com site.

You should download the document and read it to draw your own conclusions from the tests that were performed. I found the forty-page document quite heavy going with a lot of technical results (that I didn't fully understand) and some limited conclusions of the analysis. I did find the summaries useful, it's just that I could have used more summary and less data.

One interesting conclusion, for me, was that a single NAV Server appears to be able to comfortably handle 50 concurrent users. This was based upon the NAV Server application, being a 32-bit application that can work with 3GB of RAM or less, showing a 1.7GB memory consumption for 50 concurrent users. Obviously this is dependent on the type of hardware you are using and the scenarios your users are likely to be running. The document contains sufficient disclaimers on the findings so, as is often the nature of benchmarking results, this information is more of a guideline than a rule.

With respect to virtualisation, the team do not recommend using a Hyper-V virtualised environment for production use due to the reduced performance.

Personally I found that this document fell short of my expectations. It is clear that the team have put a lot of effort into their studies; however, I would like to see a guide to sizing hardware that is easy to use and understand. It would be nice if we could have some recommendations that answer the following questions:

• What is the maximum number of users?
  
• At what point should I separate the tiers on to three machines over two?
  
• How many users should I be running per NAV Server?
  

I would also like to see the scenarios run in the Classic architecture to see what performance benefits we get from the three-tier architecture.

My New Toy - Sony PRS-505

I’ve tried to read electronic books (ebooks) in the past but have always preferred paper books (pbooks). As my good friend Vjeko said, “I like reading lying down - and I most certainly don't like the feel of laptop lid hitting my forehead when I fall asleep :-)”

Having said all of that, I have bought a new toy that has changed my reading world and has convinced me that, whilst the pbook will probably never die out completely, the age of the ebook seems to almost upon us. The new generation of readers are become cheaper and more accessible and more and more publishers are getting their books out in ebook formats.

There are a lot of reading devices available, and if you’re interested in learning about them, I can recommend the forum http://www.mobileread.com/. I spent a while looking at the various devices on this site before a forum member offered to sell me a Sony PRS-505 second hand. I have now had the device for nearly two weeks and have finished reading “Simple Genius” by David Baldacci. David’s book is great and I really enjoyed it – he certainly is a very talented author, however I enjoyed reading the book even more because I was reading on my new reader.

If you’ve read ebooks on a phone or PDA or laptop, you’ll know that it can be a frustrating experience. The back-light on these devices can make your eyes tired. Laptops have a tendency to get hot and take a while to boot – not to mention the rate they chew through batteries. The Sony PRS-505 on the other hand does not use a traditional LCD display but instead using a technology called e-ink that has a similar effect to reading a glossy magazine it only uses power to change a page which means you will be able to read for hours and hours on a single charge. The internal storage and memory cards mean you can carry hundreds of books with you.

Incidentally, you can buy a PDF format e-book version of Implementing Microsoft Dynamics NAV 2009 from the PACKT web site. I’m looking forward to future devices that promise larger displays (good for reading A4 PDF documents) such as the Plastic Logic Reader, but for now, I’m really pleased with my new toy.

A New Home for Vjeko's Blog

Way back in February of this year, I made a post about a blog that appeared on my Google Alerts for Navision that really caught my eye.

Now Vjeko's blog has moved to a new home: http://www.NavigateIntoSuccess.com. It has a new sleek look, new features, but the same fantastic content that has kept many readers returning again and again.

If the number of comments a blog receives is a testament to it's success then Vjeko has done extremely well over this last year. His articles regularly receive many comments from readers and he always takes the time to answer the comments.

Vjeko often writes in-depth, well researched, and informative posts on Dynamics NAV and Sure Step. I am a little biased, since we have just finished co-writing a book; however, if you are not already a subscriber to his blog, go and check it out. Now that the book is finished, we will both have more time for blogging and forum posting.

Implementing Microsoft Dynamics NAV 2009

What a great way to wake up! You can now pre-order our book. I woke up this morning to see that the link to pre-order the book with a discount was up on the PACKT site. Wow!

I have co-authored this book with my good friend Vjekoslav Babić, and I can see that he's been busy blogging about the book and letting everyone know. One of the reasons I have been so quiet in the blogoshpere and on my favourite forum over the last few months is because I've been working so hard to get this book finished.

We've really tried to make this book as informative as possible, while keeping the fun elements from our blogs. There have been some fantastic people involved in producing this book, with feedback from members of the product group and technical reviewing from seasoned NAV experts and bloggers (like Eric 'Waldo' Wauters). Thanks to everyone that has read this blog over the years and to those that have left the occasional comment.

The book is aimed at consultants and developers of NAV and gives an insight into the new features of NAV 2009, and also a series of tips and tricks and practical examples for configuring, modifying, and extending the application. I can honestly say that this is the best book on NAV 2009 I have ever written.

So what are you waiting for? Go and pre-order your copy now.

Dan Brown Loves NAV 2009 (and so do I)

Well done to the product team for getting NAV 2009 released to market. It's been a long haul for them and what they've acheived is truly remarkable. Dan Brown has made a blog post on the NAV Team Blog (read it here) in which he talks about the emotion that people attach to the new user experience and you should really go and read it if you have not done so already.

I've been playing around with NAV 2009 since the first release was made available to partners in May of this year. I'd seen some pretty cool videos previously and I was surpised to find the product looked just like the video and was fast and stable. The new Role Center approach is going to take some thinking from partners and initially introduces an extra step in the configuration process, but over time I can see this dominating the entire implementation process with the focus being more on the people in the organzation, the roles they play and the processes they need to perform and less on the data and the functions that are required to work on the data.

2009 is going to be a great year for NAV and I think it's going to be a whole heap of fun putting the theory into practice. Have you had chance to use it yet? If so, leave me a comment and let me know what you think of it.

Everybody Lies

The Dr. House approach to requirements analysis

This posting was first published on the Intergen Blog Site on the 26th September.

Gregory House M.D. is a maverick medical genius who, in each TV episode, heads a team of diagnosticians in their attempts to diagnose an unfortunate patient’s mystery illness. House’s signature phrase is “Everybody lies” although, for his character, it’s more than just a saying, it’s a philosophy. In this article, I’ll demonstrate how the “everybody lies” approach can be applied to requirements analysis in order to reduce costs and improve overall project quality.

It seems odd to claim that everybody lies. Just as there’s no good reason for a patient to lie to a physician who is trying to save their life, we don’t expect a business person to lie when we’re gathering requirements. The modern-day philosopher, Homer Simpson, has this to say on the subject of lying: “Marge, it takes two to lie. One to lie and one to listen.” Homer’s insight helps us understand the fundamental problem: the users must tell us the truth but as analysts we are equally responsible for finding it.

Before I try to convince you of my rather tongue-in-cheek methodology, you should first understand that getting requirements right is a serious business. Research from Barry Boehm and Philip Papaccio has shown that defects introduced early in a project, such as in the requirements analysis phase, can cost 50 to 200 times more to fix later in the project than if they had been corrected close to the point at which they were introduced. 50 to 200 times – that’s a staggering difference!

Gathering requirements means capturing business problems, not computer problems. You don’t need to be Sherlock Holmes (or Gregory House for that matter) to understand that the first step in solving a problem is to clearly identify what the actual problem is. Building a solution based on the wrong requirements can be a costly mistake to make, but how exactly can we apply our new “everyone lies” approach to requirements analysis and avoid getting it wrong? One approach could be to shout “liar” every time a user describes a requirement, but some may find this a little disturbing. First we need to understand the nature of the lies and how to avoid them.

The first problem I have discovered is that people like to describe solutions and not requirements. If I had a signature phrase for requirements analysis it would be, “That’s not a requirement, it’s a solution!” I’ll admit it’s not as catchy as “everybody lies” but the sentiment’s the same.

A requirement is the answer to a “what” type of question and should always be expressed in business terms. A solution is more of an answer to a “how” type question. There’s an easy way to tell the difference between requirements and solutions: if you can implement it, it’s a solution.

Writing down a solution instead of a requirement happens frequently, but most of the time we get away with it because it just so happens that the solution we’ve written is correct. No harm, no foul; but what happens when the solution isn’t correct? Remember that equation we had before? 50 to 200 times more expensive to fix. That’s why we get the requirements signed off to make sure they’re correct, because no-one would sign off on requirements when they’re not correct. Or would they?

Having a signed off requirements document means nothing if the requirements are wrong – we’re still going to need to fix the defects and our goal is to reduce the project costs, not just our costs. Let’s assume that no one would sign off requirements that they know to be wrong, so it must be that they’re not understood, but this raises a new mystery: why do people agree to requirements when they don’t understand them?

The problem starts when we use the wrong language to describe requirements. If we’re not using business terms, we’re putting the business users at a disadvantage. It can typically go one of two ways: either the business user says, “Hey I’m sorry but I don’t understand this requirement so I can’t agree to it”, or they say, “I don’t understand this requirement but the consultant seems pretty confident that he’s right, so I’ll just keep quiet. If it’s wrong someone else will pick it up later on.”

So the next time you find yourself writing a requirements document, remember that you’re a detective and not a secretary. It’s your job to find the real problems in business terms and not simply record what you’re told. When people tell you that the captured requirements are correct, ask them to explain them to you, just to check they’re not lying.

In my next post, I’ll explore the “Tourette’s Syndrome” approach to handling support calls.

Awesome Vista Sidebar Gadget

App Launcher

I've only just started to use Vista's Sidebar gadgets in anger. Sure I had the inevitable clock and the Weather forecast and even a calendar but the few times I had searched for something in the gallery I came up with a real "meh!"

Today a colleague pointed me to this App Launcher gadget and I think it's brilliant. I love the fact I can just drag shortcuts on to the gadget to add them to the launcher. I love the fact that folder shortcuts open in the flyout and that I can open my Internet Explorer favourites too. I'm guessing the fact I have a widescreen monitor and the Gadgets are always on top helps. If you're not using Vista, then poor you. If you are using Vista and you haven't seen this one, you should really give it a go. Click on the link at the top of this post to download.

Intergen in top 5% of Microsoft Dynamics Partners

Intergen has been honoured with membership of the 2008 Microsoft Dynamics President’s Club which consists of the top 5% of Microsoft Dynamics partners worldwide.

Intergen received this top recognition from Microsoft during the Microsoft Worldwide Partner Conference 2008 in Houston, Texas. The honour reflects Intergen’s dedication to meeting their clients’ needs.

It's a great feeling to be part of a team that is recognised at this level. To read more, visit http://www.scoop.co.nz/stories/SC0807/S00056.htm.

I love TRANSFERFIELDS.

I've been doing a fair bit of coding recently and I must admit I love the concept of transferfields and the simplicity. It's really nice to know that when a customer wants a field to work it's way through to the posted documents from the source documents, you can do it all without writing any code.

Still, it would be nice if there were a way of stopping it from going wrong.

I hate TRANSFERFIELDS - Part II

I hate the TRANSFERFIELDS command. The last time I ranted about it I seemed to stir up some strong feelings, so I figured it’s time to bring this one up again.

Last time I commented on how the unsuspecting developer has no way of knowing what is going to happen when they use this command due to the way it copies fields between tables using the field ID to map the tables. Since then I have been tripped up again by this evil function and instead of simply moaning about it, I thought I would suggest an alternative.

So here I am going to introduce the all-new transferfields functionality. Microsoft, please feel free to take this idea and implement it in NAV.

The TRANSFERFIELDS command is programmed the same as now but in order to use it, a field mapping between the two tables must be defined at the table definition level. Let’s say we want to transfer fields from the Purchase Header table and the Purch. Inv. Header tables. You can find an example of this in the Purch.-Post codeunit as follows:

PurchInvHeader.TRANSFERFIELDS(PurchHeader);

This line takes the fields from the PurchHeader record variable and transfers the fields to the fields with the same field ID in the PurchInvHeader record variable.

If you have not defined a filed mapping between these two tables, the above code will not compile. In order to define the mapping I see it working like this.

Go to edit the Purchase Header table and select View menu and select the Table Mappings option. This will launch a form similar to the following:



On this form, you can insert a new line and enter the To Table ID to identify the table you want to map to. It would probably make sense at this stage for the system to automatically insert mapping between the two tables based upon the matching field IDs of the two tables. In this respect replicating the existing behavior would be pretty easy.

To customize the field mappings for the tables, the user will simply click the assist edit button on the Mapped Fields field and this will show the Field Mapping form.



Here the user can set up the field mapping. There are a couple of great things about this approach, you can ignore fields that you would never want to copy, such as the No. field. You can also map fields with different IDs. The other great thing is that field mappings can be managed by end users without the need to write code. An example would be if the user creates a new custom field on the Purch. Inv. Header table called Original Purchase Order No. The user can then make sure that the purchase order number ends up in this field by just using the mappings.

We could even add some rules on what to do when the fields don’t match in type, i.e. should we truncate the string or throw a run-time error.

Help!

In May I wrote a short piece for MSDynamicsWorld.com on on-line help and offered some thoughts on how it could be improved. In response to this article, I received a question asking how to configure the online help in Dynamics NAV.

In truth I have never done this. I knew I had read a document on how to do it but to be honest, it looked so hard I didn't bother. When I came to reply with the details, I really struggled to find the document I was looking for that described the help creation process. If you're looking for it, it's called NOHG.pdf

One of my points in the article is that we really need an easy-to-use help editor, similar to the one in Dyamics AX. Doh! I can't believe I just admitted something was better in AX!

User Acceptance Testing - the Key to Surviving an ERP Go Live

This posting was first published on the Intergen Blog Site on the 12th June.

When I came to New Zealand, nearly six years ago, I wanted to throw myself off a bridge with some elastic tied to my legs. I had heard that this was something Kiwis did and I wanted to fit in to my newly adopted environment. The world’s first commercial bungy jump started in the mid ‘80s in Queenstown, New Zealand. And it was there, on the Kawarau Bridge, that I took the plunge in 2002.

It was frightening but totally worth it. I knew it was safe but that didn’t stop me from being absolutely terrified. Sometimes in life, no matter how scared you are, you need to take a leap of faith. 5, 4, 3, 2, 1, bungeeeeeeeeey!

There are some similarities between bungy jumping and going live with an ERP solution and it was thinking about those similarities that inspired me to write this piece. Don’t panic, I’m not going to try and contort what I have to say about the ERP go live process to be all about bungy jumping using some clever metaphors. If, however, you do find yourself standing on the edge of an ERP implementation, you should read this article before jumping head first.

First of all, let’s consider the timing of the go live. How do you know when an ERP implementation is ready to go live? Is it when you have run out of time, or money? Often those, or some other seemingly arbitrary factor, are the main reasons for deciding on a go live date, but are you really ready to go live and how do you know?

The Six Ps

Like many things in life, prior preparation prevents pretty poor performance. In the case of an ERP implementation, the preparation comes in the form of user acceptance testing (UAT). User acceptance testing is often used as a project milestone for contractual reasons; completing UAT signifies that the solution has reached an acceptable level of stability and this in turn can be linked with the issue of who is going to pay for fixing defects. UAT is actually far more important than that — it is your key to project success. Imagine being the first person to bungy jump from the Kawarau Bridge. You’re standing 43 metres above the river with a bungy cord around your legs. Are you going to jump because you believe it should work in theory? I think not. Before you jump you’re going to do a little testing first: maybe throw a crash test dummy off the bridge to see if the harness holds, to ensure the rope is the right length. It’s important to iron out the issues in a safe environment first, and for an ERP implementation the safe environment is UAT.

Every issue that is found during UAT is one less issue that will need to be solved after go live, and the thing about go live issues is they can be really dangerous. When an issue occurs in a production system in a go live environment, it needs to be fixed quickly, and there is typically a great deal of stress associated with the issue. Being hurried in a stressful environment does not make for good programming and it certainly doesn't allow for well thought out design.

In order to avoid this stressful and potentially business-damaging situation you must start your preparation early, but what exactly is UAT. And, more specifically, what should you be testing?

Test the Entire Solution

In UAT, you are trying to simulate your go live situation. The closer you can get your UAT environment to your go live environment, the more confident you will be that you’re going to survive. Here’s a list of some of the things you need to be testing:

• The configuration of the production server hardware and server component installation, such as database, application server, SharePoint server, IIS, report server.


• The ability to install client software. It may be that you have a dedicated set of machines for the users to perform UAT, but if you are planning on installing client software as part of your go live, you should be testing your installation procedures by installing some software on some client machines that will be used for the testing. Go live day is not the day to hear, “Well it worked in the testing room - what’s different?”


• The configuration of your production ERP environment. The testing must be performed using the system with configuration settings as they will be in the live environment. It is inevitable that you will need to make some configuration changes during UAT in order to resolve issues; however, you must ensure that the same changes are logged and applied to the live environment. And you should also be aware that any change in configuration could invalidate all testing that has been completed so far.


• The data conversion process. Your data conversion process needs to be repeatable; you need to be able to extract the data to be converted consistently, hopefully using programs or scripts with a minimum amount of manual manipulation. The import of the data must obviously be done through dataports or other programs and the UAT is where you will test the success of those procedures. If you make changes to your data as a result of issues found during testing, you should ensure you can repeat this when you do go live and document the changes to the data conversion process.


• The modifications that have been made to the system: the new reports, forms, codeunits and external programs, interfaces, and reports all need to be tested. All too often this is the only thing that is covered in UAT. Once again, corrections may mean that previously accepted tests need to be re-tested. This is known as regression testing—it’s not what you fixed that’s important, it’s the things you broke along the way that you need to be aware of.


• The configuration of security privileges. This is to ensure that users can perform the tasks they need to perform without getting error messages and also to ensure that users do not have access to the data that they are not privileged to see.

Plan your testing and test your plan

The only way to have a successful UAT is to write down what you plan to test and record the issues you have found when they are tested. When you need to make the decision to go live or not, you will want to see the list of business process with lots of little ticks against them showing that they have been successfully performed. Remember the problem of regression testing: when you make a change to configuration, data conversion, or programming, you may as well erase all the ticks you have so far – it’s not what you fixed that’s important, it’s what you may have broken. If there are issues, you want to know what they are before you go live; it’s OK to go live with issues, it’s just important to know beforehand they are there and to have taken an informed decision.

When it comes to preparing test cases—well that’s another posting in its own right. Maybe one of our QA team can offer some advice in that area.

Get Some Help

If you have done your job properly, the go live should be painless. There may be a few surprises, but by and large you’ll be going live knowing that the critical things are going to work. It’s important to have good people around to help you through the go live process. When you’re standing on the platform with your towel wrapped tightly around your ankles, gazing at the horizon, it’s good to know that if you do freeze up, one of the professionals stood behind you is going to be quite happy to give you a little push.

Partner Sauce

PartnerSource seems to be going through something of a revolution. If you use the Global English site, you have probably been using the new saucy version for a few days now. If, like me, you sign in to a localized version, you may be unaware of the changes that are coming.

So what is so good about the changes that warrant a blog post? I’ll tell you what, three little letters: R S S.

It is now possible to subscribe to an RSS feed for News, Sales & Marketing, Support & Deployment and Training & Certification, meaning you read the news in a Vista sidebar gadget, from within Outlook or on your mobile phone. But for me the ultimate feeds are the Most Recent KB Articles and Most Viewed KB Articles. Now you may think that getting excited about this is a sure sign that I need to get out more or at least get a hobby, but believe me this is going to make my life so much easier.

It seems that I am not the only one that has struggled to find out what is going on in the NAV world without a lot of digging around and checking PartnerSource every day, just in case there is something new. For more details on the changes to PartnerSource and a warm feeling of love from Microsoft, check out the link
Get Ready for Exciting, New Changes to PartnerSource

For some strange reason whenever I clicked on the RSS Feed links on the NAV product site, my Internet Explorer crashed – this was because of Skype and as soon as I uninstalled Skype on my machine it all worked fine. I will report this to the team to see if they can fix it up. The non-product site RSS feeds worked fine.

You can find the NAV-related product feeds on this page: https://mbs.microsoft.com/partnersource/solutions/nav/

Runtime Errors Suck!

I hate runtime errors. I think that functions in C/AL that can generate runtime errors should be deprecated where possible or altered in their function. Let me explain with an example.

Let's say you have two fields both called Description on two different tables. One of your tables is the Item table and the other is a new table called "New Item" (OK so I'm not going to win any prizes for imaginative table names in this example.) You want to make an assignment from one field value to another so you would do something like this:

l_NewItem.Description := l_Item.Description;

When your code runs the Description gets copied across and everyone's a happy bunny. But, let's say your customer says they want their item description to be made 20 characters bigger. What happens then?

Well let's assume that you increase the size of the Item Description field by 20 characters. Everything still works. Or so you think.

When NAV executes the line of code that previously worked fine on a record that has more characters in the new larger string than will fit in the other string, you (or more likely the first user that comes across that bit of functionality in your production system) will get a Runtime Error. Blurgghhh!

I have programmed in a few languages and C/AL is the only language I have ever come across that does this. What would other languages do? They would truncate the value and continue. They would assume, "hey, the programmer wants me to put a 50 character string in a 30 character string, he must know what he's doing, so I'll just give him as much as I can."

I like that, it's friendly, it makes me feel warm and fuzzy. Why can't C/AL do the same?

But there is a far worse function that can throw runtime errors and this should be banned altogether! TRANSFERFIELDS.

TRANSFERFIELDS is evil. It has to go.

What does it do? Well it, er, transfers, erm, fields (duh?) It is used to transfer fields from one table to another. Sounds cool doesn't it? How does it decide which fields should be copied? It uses the field ID.

What? The totally arbitrary field ID? Surely not, that would be crazy. Yup you heard it the field ID. NAV will attempt to make an assignment between two fields with the same ID, but different names and different types. And what do you think happens if the field types are incompatible?

Run Time Error.

The reason this function is evil is it lures the unsuspecting programmer into its little trap. It looks innocent. It looks like it may save you some time. Don't be lazy. Assign the fields one by one. Think about it, if you have 10 lines of code that assign each field from one table to another, anyone reading your code knows exactly what is happening. If you really want to be good, create a function on the table called CopyFromItem() or something similar. Then do the field assignments in the function so your code would look something like this:

l_NewItem.CopyFromItem(l_Item);

Now isn't that better?

So what prompted me to have this little rant? Well I am doing an upgrade from v3.70 to v5.00 at the moment and the damn thing just failed with a run time error. Some of the code in the standard upgrade toolkit gave me this error message:

The two fields below must have the same type:  
Field: JobTaskNo <-- Table 
Table: Temp Job Task Phase Step Comb. <-- Temp Phase Step Task Doc Line 
Type: Code20 <-- Integer

Can you guess what caused this error?

TRANSFERFIELDS!

So if the expert coders at Microsoft get caught out, what chance do we have?

Try Catch in Dynamics NAV

This has to be up there on my list of "all time desirable features" for NAV. As you probably know NAV has an ERROR function that is used to, well, throw errors. It will abort the current transaction (and roll back to the point of the last commit) and display the text message that you selected in an error dialogue box.

The thing is, sometimes you don't want it to do the abort and rollback. For example if we are importing a file or maybe a series of files, we may just want to log the error somewhere and carry on with the next file. You can do this in NAV 5.0 using the new GETLASTERRORTEXT function.

Here's an example of how to do it.

First of all, create a simple codeunit that, when run, will throw an error:

OBJECT Codeunit 50000 ThrowError
{
  OBJECT-PROPERTIES
  {
    Date=09/04/08;
    Time=[ 9:34:55 PM];
    Modified=Yes;
    Version List=;
  }
  PROPERTIES
  {
    OnRun=BEGIN
            // Call a function that throws an error.
            DoSomething();
          END;

  }
  CODE
  {

    PROCEDURE DoSomething@1000000000();
    BEGIN
      ERROR('Hey Look I threw an error.');
    END;

    BEGIN
    END.
  }
}

When you run this codeunit you get the following error message displayed.



Now create another codeunit that will call the first one and trap the error it generates:

OBJECT Codeunit 50001 Test Throw Error
{
  OBJECT-PROPERTIES
  {
    Date=09/04/08;
    Time=[ 9:35:58 PM];
    Modified=Yes;
    Version List=;
  }
  PROPERTIES
  {
    OnRun=VAR
            l_ThrowError@1000000000 : Codeunit 50000;
          BEGIN
            IF NOT l_ThrowError.RUN THEN
              MESSAGE(GETLASTERRORTEXT+ ' - or did I?');
          END;

  }
  CODE
  {

    BEGIN
    END.
  }
}

When you run this second codeunit, even though it calls the first codeunit, you don't see the error message. Instead you see this:



You'll need to make a COMMIT before trying to trap the return code from running the codeunit but if you have uncommitted transactions you'll get a run time error telling you this. Unfortunately this only works when you Run a codeunit so you either have to use lots of codeunits or write some kind of clever dispatcher that allows you to set the action on the codeunit first and then run it.

So my most desired feature would require some language additions to C/AL. Introduce a TRY CATCH language construct – it would work similar to an IF ELSE statement. Here is an example:

TRY
  BEGIN
    DoSomething();
    DoSomethingElse();
  END
CATCH
  BEGIN
    MESSAGE(GETLASTERRORTEXT);
  END;

I have put the BEGIN and END in the CATCH part to illustrate how it work in a similar manner to the IF ELSE construct but it wouldn't be needed. The neat thing about this is you would not need to use a codeunit just to be able to trap the error. The same rules regarding commits, etc. would apply.

I guess I'll just nip over to the Connect site and suggest this little beauty for the product team to ponder over.

Get Stuff Done – Go Home Early - Play with your Wii

I've been using ActionThis since the early beta stages and I love it! The ActionThis team are running a promotion whereby you can sign up for a 1-month free trial if you sign up with the promotional code. After that you can continue to use the website for free!

Click this link to go to the site http://www.actionthis.com/product/trial.aspx

Enter the Referral Code INT521

You can use ActionThis to help you and your team work together more effectively, using the power of the web combined with Microsoft Office.

Thousands of people worldwide use http://www.actionthis.com/ to manage the tasks small businesses, teams and their partners need to complete to succeed. Delegate tasks from Microsoft Outlook, connect with your team on the ActionThis task management website, track progress and take action with live reports delivered to your email inbox. ActionThis is free to try, and simple to use. Less time following up, more tasks completed, your business is more productive. ActionThis was designed and developed by Intergen in New Zealand and will help you and your team get things done.

How ActionThis helps you get stuff done:
Use Microsoft Outlook to create and assign tasks to yourself, your team, your partners,
Organize and access these tasks from anywhere using Microsoft Outlook or the http://www.actionthis.com/ website,
Keep track of progress, projects, and workload with reports emailed to your email inbox,
Keep on top of overdue tasks with live alerts designed to help you take action quickly,
Export and analyze your progress with Microsoft Excel,
Telephone and email support is free.

Try it for free. Sign up for a one month free trial at http://www.actionthis.com/product/trial.aspx and use this referral code: INT521.

Dynamics NAV Gets Connected

In my first ever blog post I wrote about a site where ideas for new product features can be posted. Today I came across a news article on PartnerSource that pointed me to a new place for logging feature enhancements, the Connect for Microsoft Dynamics site. You will need to register a Windows Live ID in order to use the site, which site is a big improvement on the old public forum.

Microsoft seems to be committed of late to listening to feedback from partners and customers and this is a very welcome move. Recently they requested feedback on how the online help can be improved through Convergence and some of the public forums. This new listening, caring Microsoft makes me feel warm and fuzzy and I truly believe that we should all be feeding back to Microsoft where we think the product can be improved. Long gone are the days when this was a pointless exercise, so sign up and give it a go!

The site seems to have been active since October 2007 but there are only 7 suggestions for NAV – maybe it hasn't been that well publicised? Well here's a suggestion to get things going. If you want to vote for this suggestion you can register and click the rating. Here is the suggestion:

Every implementation of NAV I have ever been involved with has a test system and a live system. I am assuming this is a universally accepted practice – you don't want to be applying programming modifications to your live system without testing them first. In nearly every implementation of NAV I have been involved with, there have been instances at least one user has been logged in to the live system and thought they were logged in to the test system and they have mistakenly posted entries in their live system. The request I commonly receive is to make it so that it is immediately obvious to the users which system they are in: live or test. This should be immediately visually obvious – to me there is only one way to achieve this and that is to change the colour scheme of the windows. You can change the text in the title bar (via 3^rd party utilities or by renaming the company) but this is not immediately visually obvious. Another less common requirement is for users that need to work in more than one company at once and they want to see which company they have open. Again they want something that is instantly obvious and don't want to be reading titles of windows. So my suggestion is: allow the Window Colour and Appearance options to be specified at a Company AND Database level. The Database level is required so that if a user restores their live system over their test system (something they frequently need to do) they do not lose the all important colour settings. At the database level it could be stored in a table similar to the $ndo$srvproperty table in the master database – this would have one record for each NAV database. Restoring a database would not overwrite this value. At the company level, it would be set in a table that is company specific.

Look at me! I’m a balloon!

This has got nothing to do with Dynamics NAV so if you're looking for news on ERP systems, leave now. If you are squeamish about medical procedures then you should also leave. Hi Dad – just you and me reading this now.

I am gluten intolerant. That means if I eat anything with Gluten in it I feel crook. Today I went for a Esophagogastroduodenoscopy to see if I have coeliac disease (the disease sounds bad but basically it means you can't eat gluten without it making you crook and you have damage to the bits of your gut that help you absorb nutrients.) There is no cure other than to stop drinking beer, eating pizza, burgers, toast, pasta, etc. So, not too bad, right?

Anyway, back to the procedure. I was given the choice of a local anaesthetic spray (that numbs the throat) or the spray and a sedative. I was told that if I had just the local I would be able to watch the procedure on a video monitor. I was also told that the guy before me just had the local and he was able to keep himself calm, control his breathing and he got through it fine. I was also told that the sedative would make me feel drowsy and unable to do pretty much anything for the rest of the day. I was attracted to the idea of watching the procedure on the video monitor (my wife says this is the geek in me winning out of the sensible part of me.) Now if you ever find yourself in the unfortunate position to be asked if you want a sedative before someone shoves a piece of hose down your throat and pumps your stomach up like a balloon, the correct answer is "Hell yes!"

As for the video: the doctor stood in front of my screen so I didn't see a thing! But the procedure was so unpleasant that there could have been a small family of pixies living in my stomach and I wouldn't have cared. There were several people watching the procedure (I am guessing they were students) and none of them would make eye-contact afterward. This was probably due to the strange retching-gagging-belching noise I was making and the look of fear on my face. I think they were thinking "Dear God! What did we just do to that man?"

So the purpose of this blog posting is that if anyone is searching Google with the question: "Should I take the sedative before having an EGD, OGD, upper GI endoscopy (UGIE), or gastroscopy" then they can read this and know that no matter how appealing seeing their insides on a video screen seems, you should take the drugs!