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?