I use the Jobqueue as much as I can for automating jobs. It’s decent, stable, good, flexible. It makes sense, doesn’t it? But after installing a language pack (NLB and FRB – quite common in Belgium :-/) .. it didn’t seem the most valid opinion I had.. : my RTC was crashing 10 seconds after I started the NST.
This is what I set up for the NAS:
Not very exciting .. Not much that can go wrong. But after restarting the NST, I noticed I couldn’t log in the RTC .. . The Service had stopped, 10 seconds after it was started. This is what I found in the event viewer:
A Dutch error message.. which (for me – and hopefully also for you) means that this error is due to language issues.
I found a solution .. but I’m not sure this is THE solution that should be implemented. I logged the problem at Microsoft, so I hope to have a better solution in the near future.. .
It could be that my problem was the default language of my startup user (which is different from the default). Could be. But do I care? Not at all, actually. This should work at all times, in any language my user is configured.. . So I decided to try to go as much as possible to the “core” of my problem: the Job Queue.
It seems to be that starting (background) sessions with the job queue is very dependent on the language, so let’s always start those sessions in the same language that always works: ENU (being language 1033).
That’s why I changed the NAS codeunit of the Job Queue (codeunit 450) by adding one line:
This way, all background sessions will be started in ENU (which seems to be required).
When I read the comment – it confirmed that I was probably searching in the right place – having found a reference to the 10 second delay :-).
Again, I hope there is going to be a better solution in the future .. If you have one .. Please make a comment :-). I would really appreciate it, because I feel like I’m overlooking something so obvious. But hey .. in the meantime, I (and you) have a solution ;-).
One might wonder: do I want my NST to crash if my NAS is down? No, of course not! In fact, regarding stability and scalability, it’s always best to install separate services for this .. . With the Dynamics NAV Administration Tool, this is very easy to do. If you would like to show you .. just drop a comment :-).
I was wondering if the nas was executing any jobs and the messages was dutch because the text constant was in only avaiable in Dutch.
But the error looks like the standard C/AL error when using an invalid Option value.
So it seems more like a bug.
Oh, but it’s definitely a bug in how the codeunit/session is started.
I’ve been having this problem on more then this area alone.. but I can’t put my thumb on it (yet..). It’s only, in the area of starting NAS processes (the case above), I guess the workaround (let’s call it that) above makes sense.. .
I’ve been having quite the same issue when I do a CODEUNIT.RUN in code .. but that went away when switching languages on my classic client (you read it right.. doesn’t make sense at all). Now it doesn’t come back anymore .. so debugging or investigating is quite difficult at this time..
So .. definitely a bug .. but seems one in the kernel, not in C/SIDE or C/AL ..
but then again, I haven’t had the time to really put my thumb on it.. . I hope I will get some comments on this post that will push me in some directions 😉
This is the same problem as in the fin.exe command line : you need to use the same language in the command line as in the stx file.
So if you create a shortcut with “ntauthentication=yes” and start the client in a non-english language you will get the same error msg,
The solution is use Integer for Boolean (and possibly Option) fields : “ntauthentication=1”
You’re very right, Marton. That’s what I recognized as well .. but then again .. isn’t NAV2013 fully RTC? :-/ In my opinion, it doesn’t make sense at all.. . I have been searching for such a parameter in a lot of setup and config files, and didn’t find any parameter like that.. . Do you have a clue?
Thanks for the comment 🙂