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
- Import Budget from Excel
Oops … 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.
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.
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?
@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).
@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.