What To Think of This? – A Tester’s Nightmare

The other day I had the task to customize the Import Budget from Excel and Export Budget to Excel batch jobs. To incorporate changes made in Financial Management as part of a major add-on we are building. Although the add-on is directly implemented for RTC, I decided to first get the batch job working on Classic as it would enable me to easily debug and stay as close as possible to standard code. Unexpectedly I got the whole thing working very easily, so I set off in a very good mood for RTC.

  • Export Budget to Excel
    No problema
  • Import Budget from Excel
    Oops … error

Error

Of course I had clicked the error away before I could have read it well, probably thinking that I had done something wrong. So another run and … error:

 

Typically a programmed error and apparently now, on RTC, code was touched that wasn’t on Classic.

Help, I need a debugger!

Up till now I had managed to circumvent debugging RTC using Visual Studio. But clearly from now on no way to get around it, unless I would drop the whole customization task on someone else’s desk. Well … no option, really. And, honestly, if someone in our team should pick up learning to debug RTC I think all fingers would point at me anyway.

VS Debugger

So I roamed around looking for info on how-to. And it showed not that difficult at all. Well, OK, I am not a fluent C# reader, but I seem to manage; not in the least through the original C/AL code lines having been inserted in the .cs files as comments. [:)]

Equipped with this knowledge and VS set up right I went off going through the code step by step, meanwhile

  • Learning to understand both C# and the code as such
  • Facing IF … THEN … ELSE constructions where in C/AL  this was CASE statement (so more steps!)

But all to no avail.

Every time the code execution stopped at the same error. Out-commenting the error throwing code made the import batch job stop at other code throwing errors; and another, and …. All code not touched in Classic Client.

Because of other tasks planned I had to let loose of the issue for a couple days, returning to it last Monday in high spirits.

Started RTC and opened the budget page to execute the import again.

%&!^$&!#)(*$!$&!#_*

ERROR AGAIN!

Patience, Luc. Was that my guardian angle?

OK, I will.

So I went into a more detailed analysis mode with less data in the Excel file and I analyzed the import in all aspects seeing the code translate the Excel structure into a set of records. Understanding exactly what the code was doing. And of course in Classic Client as the batch was working fine there.

RTC, here I come. Lucky Luc! (I truly was hoping)

Set up VS. Started RTC. Ran the process as before. Error again.

So now I wanted to watch the ExcelBuf variable and see whether the Excel data were transfered right into NAV records. It showed what I expected. Same details as I had seen on Classic Client.

And as all Excel cells where copied to NAV I hit F5 to let the process continue to the end without stepping through the cod,e awaiting the well known error. Waiting … progress indicator continued … waiting …

?!?!?!?!?!?!?!?!

Well, let’s click Yes.

?!?!?!?!?!??!?

A TESTERS NIGHTMARE!

Just running the debugger in a somewhat different mode solved the issue. Well, at least gave the desired behavior.

Now I did rerun the process a couple of times and the result was OK every time. Wonder what will/can happen at customers once you would go live with this.

When they call because of an issue should we suggest to turn on VS debugger, select a variable to watch and run it again. Problem solved!

Hey, you, C# experts! You, VS wizards. Any idea why this is happening like this? And .. can I trust NAV (RTC) to run well from now on?

2 Comments

  1. @Natalie: never did get into such a situation with classic debugger. So good to informed, but also a bit scaring.

    @Dave: good that you ask. An omission in my post: indeed I did test it with the original file and it worked also after the 'miracle'. BTW: before setting the watch as described above the import of the smaller file also threw the error(s).

  2. @Guido: thanx for this. However, having read that msdn blog, I am still left with the fact that even without debugger my bug does not appear anymore.

Leave a Reply

Your email address will not be published.