Please Help!!! Error 18 in Module 244

ziamanna

I am currently using Navision 3.70 with a Native Database. I have been facing the following error on the Navision Server:

Error 18 in Module 244 Server.C(......... and it goes on

I have had this problem for about nearly 6 months now and understand head or tail how tol solve it. I had read earlier that it has to do with Network and hence i changed the NIC of the server and got the network audited. Apparently there were no issues in the network. Even the NetTest results are very good. I even tried restoring the database on different servers since i thought it may be a hardware issue but every server that i put it on gives me the same error.

Has anyone actually found the root cause and an error solution path to this?

Regards,
Zia

ara3n

I would call MS, they are the only ones who could help you resolve the issue.
The other option is to get the latest executables 4.0 sp3.

Also I believe MS has stoped supporting 3.7. They only support 4.0 and up.

David_Singleton

ziamanna wrote:

I am currently using Navision 3.70 with a Native Database. I have been facing the following error on the Navision Server:

Error 18 in Module 244 Server.C(......... and it goes on

I have had this problem for about nearly 6 months now and understand head or tail how tol solve it. I had read earlier that it has to do with Network and hence i changed the NIC of the server and got the network audited. Apparently there were no issues in the network. Even the NetTest results are very good. I even tried restoring the database on different servers since i thought it may be a hardware issue but every server that i put it on gives me the same error.

Has anyone actually found the root cause and an error solution path to this?

Regards,
Zia

Its important first to realize that the error is not likely to be an error on the server. Server are generally built with high end equipment, and their network cards are generally reliable. This error, just says that somewhere on the network there are bad packets. It deos not tell you which computer is causing the error.

At one client, we eventually found out that the error was a printer that had an IP adapter connecting it to the network. That printer was never used by Navision, it was just on the network, and if a user printed a very big print job to that printer (not from Navision), and then someone was running a network intensive task on Navision such as Inventory adjustment or creating a backup, then often Navision would crash with the error. Removing the printer resolved the problem.

What you need to do is to try to locate the faulty network card, and that can be a huge job. We ended up just creating a dummy server and two clients that just ran dummy tasks all day till it crashed, and we had a network sniffer that monitored packets, and evenutally we narrowed dwon the error.

Of course prior to this, we had some "network professionals" come out with all the gear, and they gave the network a clean bill of health. But keep in mind that if you can not re-create the error, then its unlikely that normal network testing is going to find it either.

By the way, if you have any hubs on the network, dump them immediately and replace them with switches. Sometimes that can isolate the bad network card from Navision.

Good luck.

OH and of course your error may be something totally different.

Timo_Lässer

Internal error 18 in module 244
Error Code: 15990802
Description: #Err_NC_ECONNRESET

It means that the server does not response.

David_Singleton

Timo Lässer wrote:

Internal error 18 in module 244
Error Code: 15990802
Description: #Err_NC_ECONNRESET

It means that the server does not response.

You could be right, From the description of the issue, I was thinking it was the
Error From Network error, but now that I check, I see that that is 244-14, not 244-18.

An ECONNRESET is more likely to be Backup software trying to access the Navision Database, or some virus or other program scanning ports.

kriki

[Topic moved from Navision Financials forum to Navision forum]

ziamanna

Thanks for all your replies!

I am actually doing exactly what David has suggested about checking where in the network the problem arises. I hope i manage to resolve it soon, as currently only re-booting helps in solving the problem temporarily.

David: Any good network monitoring tools that you would suggest for this?

David_Singleton

ziamanna wrote:

Thanks for all your replies!

I am actually doing exactly what David has suggested about checking where in the network the problem arises. I hope i manage to resolve it soon, as currently only re-booting helps in solving the problem temporarily.

David: Any good network monitoring tools that you would suggest for this?

Glad to be of help so far.

Unfortunately I don't know what was used to eventually locate the faulty device. The client got in a good network specialist, I told them as much as i could work out, and they then did the monitoring. They were using a hard ware based device, not just a software package on a PC. The faulty device in the end was one of those small boxes that just has a Cat 5 plug on one end, (actually only 10M) and a parallel port on the other. When they found it, they just threw out every one of those boxes they could find, and used a different brand. System worked perfect after that.

ziamanna

David, was your client on Native Database at the time or was he on SQL Server?

David_Singleton

ziamanna wrote:

David, was your client on Native Database at the time or was he on SQL Server?

Actually both :shock: The client's NSC had originally planned for a Native install. This was just when 3.60 was released, and they were not happy with that release on SQL, and also there was no driving reason to be on SQL. But during the implementation phase, the business changed somewhat due to a buyout, and certain business requirements of the new owners, made SQL a better option, so it was decided to continue application development and testing on Native, but data-conversion and go-live would be planned for SQL on the basis of waiting for 3.70. With a fall back plan to Native if the performance was not acceptable.

So in fact we were running the same system on both, and the error happened on both systems. So it it was not server dependent.