ADCS Application Server Error "Automation variable&quot

Per

We have a couple of customers getting a problem with Live ADCS installations. The problem occur when multiple terminals are connected to the NAS. In the event log will it look like this.

This message is for C/AL Programmers:

This Automation variable has not been instantiated.
You can instantiate it by either creating or assigning it.

It is a few lines of code in the Codeun it 7700 that copies the XML document to a variable and then try to read it. But the variable is blank when it tries to use it. The code normally runs OK, but once in a while will this happen and stall the client so the handheld needs to restart the connection (reboot).

I think it is in this code.
ComComIn::MessageReceived(VAR InMessage : Automation "''.IDISPATCH")
InMessage1 := InMessage;
CREATE(xmlin);

InStrm := InMessage1.GetStream;
xmlin.load(InStrm);
InMessage1.CommitMessage();

IF TempXMLQueue.FIND('+') THEN
TempXMLQueue.Integer := TempXMLQueue.Integer + 1
ELSE
TempXMLQueue.Integer := 1;
TempXMLQueue.Job.CREATEINSTREAM(InStrm);
xmlin.save(InStrm);
TempXMLQueue.INSERT;

If anyone have experienced similar issues or have found a resolution would I be very happy to know.

Thanks

DenSter

I've seen that too, and it went away when I explicitly did some object maintenance in the codeunit. Try this:

IF NOT ISCLEAR(xmlin) THEN
  CLEAR(xmlin);
IF NOT CREATE(xmlin) THEN
  ERROR('could not create DOM Document');
IF NOT xmlin.load(InS) THEN
  ERROR('could not load the XML message');

That way you have a better idea what went wrong in the event viewer.

It might also have something to do with the fact that you are using InStrm for reading the incoming message and also for saving the XML into the Job field. Try clearing the variable between the two tasks, or have two Instream objects.

Maybe you can directly assign the incoming Instrm to the Job field, have you tried that?

Pieter

Hi Daniel,

We are experiencing similar problems with one of our clients.

Can you please tell me on what version of Navision did you fix this problem?
I would also like to know what version of ADCS was used, as well as possible service packs and hotfixes.

Did your solution work? Did it solve the stall problem?

Thanks
Pieter

Per

The newly released Service Pack 3 to 4.00 have a totally different way to connect from the VT100 to the NAS.

All the existing problems has been solved with that version. Several changes has been done in Codeunit 7700 that needs to be implemented too.

A Knowledge base article is also available that solves the issue for earlier versions.

pberb

Per wrote:

A Knowledge base article is also available that solves the issue for earlier versions.

link please?

Per

This is where you can find the SP3 files.
https://mbs.microsoft.com/partnersource/downloads/servicepack/microsoftdynamicsnav40sp3.htm?printpage=false

nomadsteve

I had the same issue with Navision 3.70A during lots of activity against the ADCS

This solution worked well for us:

In the ComComIn::MessageReceived() function I changed the following code
=== === === === === === === === === === === ===
IF TempXMLQueue.FIND('+') THEN
TempXMLQueue.Integer := TempXMLQueue.Integer + 1
ELSE
TempXMLQueue.Integer := 1;
TempXMLQueue.Job.CREATEINSTREAM(InStrm);

xmlin.save(InStrm);

TempXMLQueue.INSERT;
=== === === === === === === === === === === ===

to this:
=== === === === === === === === === === === ===
LastQueueInt := 0;
IF TempXMLQueue.FIND('+') THEN
LastQueueInt := TempXMLQueue.Integer;

TempXMLQueue.INIT;
TempXMLQueue.Integer := LastQueueInt + 1;
TempXMLQueue.Job.CREATEINSTREAM(InStrmQueue);
xmlin.save(InStrmQueue);
CLEAR(InStrmQueue);

TempXMLQueue.INSERT;
=== === === === === === === === === === === ===
(declared a new local variable LastQueueInt as int. I also used a new InStream variable (InStrmQueue) so as not to cause confusion with the InStrm variable used earlier in the code.)

My guess is that the ComComIn::MessageReceived() function is writing to the TempXMLQueue table at potentially the same time that NTimer::Timer() function is reading & removing records.

By performing an explicit INIT on the record, the MessageReceived() function is starting with a fresh record rather than reusing the record it found with the FIND('+'), which could be in the process of being deleted by the Timer() function. Or something like that. This is only a guess since I don't know how Navision deals with concurency issues.