[SOLVED]NAS can not read updated Allow Posting From/To?

allenyyzhou

Hello, everyone.
I encountered a weired problem, I have a NAS run in NAV 2009 R2, which import I/F data and create Item journal/General Journal and Post automatically, problem is I will update the Allow Posting From/To for the NAS runner every month. But everytime there will be "The posting date in not within you allowed posting...." kind of error, If I restart the NAS, there will be no error. Seems like if I do not restart NAS, it will not read the updated data from User Setup table, but when I tried in Local it went quite well. Does anyone faced the same problem before?

geordie

How do you update the Allow Posting From/To fields? If you are basing the calculation on WORKDATE testing with the client cannot replicate the exact same conditions of running it via job queue.

Kishorm

I've had similar issues before with NAS using cached data, try calling GETLATESTVERSION at the start of the code that is called by NAS.

einsTeIn.NET

GETLATESTVERSION is only needed when your data might be changed after you read it and the instance of your object (where you read the data) is still existing. That could happen if you have e.g. a long-term running transaction or you use single instance codeunits all the time.

Assuming you want to execute a recurring task in NAS, of course, the starting codeunit needs to be single instance because the instance of the Timer component must remain in memory (or the Event trigger of an external component needs to be available or something like that). But all the other Objects that are used during one execution of the NAS task could be normal Objects. That way you make sure that it's dropped from memory after it was used and will be created newly in the next execution. No old data will stay in memory. This is somewhat comparable to the garbage collector of other programming languages.

allenyyzhou

Thanks for your reply.

To:geordie
I let user click a button 'Update Posting From and To' to update the Posting From/To, for example, at the end of July, when user click 'Update Posting From and To', system will update the Posting From/To to 2014/08/01-2014/08/31.

To:einsTeIn.NET
Do you suggest to set the Job queue called Codeunit to SingleInstance? Actually the Codeunit is only for NAS.

Now I have two solution, one is set my NAS runner's [Posting To] to "9999/12/31", but my customer may feel not good about it. Two is write log to show which Posting From/To has been got when codeunit run, but if I proved that the date I got is before updated, then what should I do? Restart NAS service every night?

einsTeIn.NET

allenyyzhou wrote:

Do you suggest to set the Job queue called Codeunit to SingleInstance? Actually the Codeunit is only for NAS.

Job Queue already uses a single instance codeunit (448 "Job Queue Dispatcher") to make sure the timer based schedule works as long as the NAS runs. From that point of view there's no need to use single instance codeunits later on in the job.

Kishorm

Yeah, I know what GETLATESTVERSION does - it's just that it did fix a similar problem I had even though technically I shouldn't have had to use it. I don't know if it was a problem with a particular build or not and I don't think it was consistent either. It's worth giving it a go to see if it works for you or not.

einsTeIn.NET

Sorry, I didn't want to say GETLATESTVERSION is wrong. I just wanted to point out that there's a certain reason why it could help. That's f.i. either an issue with the Build No., or confused settings of property SingleInstance, or long-term running transactions, or something else. You're right, in any case it's worth to give it a try. But if it helps then you should check why it helps and find out the reason behind. In my opinion GETLATESTVERSION is only a workaround in this case and afterwards you should work on the reason in background of that issue.

allenyyzhou

Sorry, this is a very old post, please allow me to update something.
Microsoft also suggest us to use "GETLASTVERSION", but I did not do it. until now, two years passed by, there are two or three times same issue happened, our client choose to manually dealing with it.