Problem: Users are getting “Internal error 1355 in module 19” error when scrolling on forms. This happens randomly for different users, on different forms, several times per day, no matter how many users in the system. At approximately the same time the database server records in the application event log, one or the other of the following errors: " Error 18 in module 244" - which is caused by the socket not properly closed on the client side. Connection was lost to a client on the communication channel while reading or writing occured. " Error 3 in module 244" - which means that connection was reset by the remote side. Background: Navision version 3.10b, database version 3.10a. It is a 80 user installation, that went live September 3rd, 2002 on brand new up to date equipment. The Navision Server is installed on a Win2000 Server with SP2 on a machine with 2GB of RAM and dual processor. DBMS cache is set to 800 MB.The database has 8GB and it is 65% utilized, spread over 5 drives in an array of 5 disks using RAID 1. The Navision Client is installed on two Citrix Servers with load ballancing (Citrix XPA 1.0). The network is at 100 MB/S and performance is good in Navision and other apps. There is at least 1GB of free space in all logical drives, so disk space is not an issue. We performed the Navision NET TEST and both disk read/writes and network traffic performance between the servers that have the Navision Client and the database server are excellent. In fact it shows the network as underutilized. TCP/IP hasn’t generated problems in any other application in this network. We followed most of the suggestions from this User Group discussions, and placed a support call at Navision US, but still haven’t found the cause of this problem. It looks like a synchronization problem on scrolling, most likely a Navision problem. We are thinking about installing the Navision executable 3.60. Any other suggestions to try to solve this problem?
hi, i’ve found a solution in navision spanish official forum, so i’ll try to translate and explain… (my english isn’t so good, sorry!) one spanish partner had the same problem and did the following: - Database security backup. - From Database - Information - Tables - Test (small tables in groups, bigger tables one by one). On errors testing tables, they opened table design, deactivated all index, and added a field to primary key. Saving table made a forced reindexing. After that, they returned to table design and leave primary key as it was before modifications and reactivated the deactivated indexes. They reindexed and returned to test the table (with no errors) and so on with the rest of tables. Only table 110 returned errors and no changes were possible to made… They did as follows: - Show by screen from start to the last record it could show without errors. They exported all records from first to the last ok (the last without errors) - Show by screen from end backwards to the last record it could show without errors. They exported all records from last to the last ok (the last without errros) Doing so, they obtained all ‘good’ records in two files. Table 110 was renumbered to 70110 and a new 110 was created. The two files were imported into this new 110 table. In table 70110 all exported records were deleted, in order to leave in this table 70110 all the records with errors. They had two companies, so they change the DataPerCompany property, to create a new database with the backup which contains data from both two companies and to aislate the corrupted table They say this proccess is so hard to explain and harder to do, and also say that when they try to delete table 70110 it causes a database error, so they can’t delete this ‘corrupted’ table Also they made a hard disk test in the server because the errors could be due to disk errors, so try in this way… This is all i can tell by now… hope it’ll be useful Regards
Thank you Micky, for your detailed reply. We did run the database tests except for the field relationships one, and we got no errors. Carmen
I have the same problem and Navision’s “solution” after months of doing nothing is to install V3.60 Client and Server. I can only describe this as a Mickey Mouse solution. Navision have to fix 3.10.
It’s funny but we meet the same problem, in a similar instalation, but using Terminal Services. The instalation is in W2K SP3, Navision Attain 3.10a with 60 clients. 30 of them connected with Terminal Services. The problem we have I think is generated by table’s blocking. So, NAvision says that international Hotfix released in 1.10.2002 will eleinate this problem, but I think it don´t Did anyone installed the 3.60, and it worked without problems?
I thought I’d give you an update on this. The 1355 error was produced in relation with two activities. One was scrolling a list - client/server synchronization problem. The other one was data entry - it seams to be related to table locking (not sure). We installed 3.60 with the hot fix and it seams to have fixed the first scenario. The second scenario is still not fixed. Our customer got it twice in the last month on Purchase Order entry. Carmen
There’s a hot fix available (for 3.10 and 3.60) that corrects this problem //Lars
Moved “Developerforum” to “Errors Ecetera”.
I had the same error. It was fixed by adding more space to the TEMPPATH destination. Make sure that you have approx. as much free space as the size of your database.
what does that mean ? :adding more space to the TEMPPATH destination in windows or where shoud i add more space ?? //heinz
Hi Heinz, If you do Tools, Options on you client you will find a field called TempFilePath. This is where you put in a path that leads to lots of space. Certainly helps in some situations. Robin