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
0
Comments
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.
Independent Consultant/Developer
blog: https://dynamicsuser.net/nav/b/ara3n
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.
Error Code: 15990802
Description: #Err_NC_ECONNRESET
It means that the server does not response.
Microsoft Dynamics NAV Developer since 1997
MSDynamics.de - German Microsoft Dynamics Community - member of [clip]
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.
No PM,please use the forum. || May the <SOLVED>-attribute be in your title!
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.
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.