ADCS and LOCKTABLE timeout

The following behavior can be reproduced with a standard demo database prepared for ADCS (create Warehouse Employee, etc.):

Use Hyperterminal (or some “real” terminal) to pick up or put some items with a standard miniform. During the input the table 5767 (Warehouse Activity Line) is to be modified. If now some other navision client keeps this table locked for at least 5 sec (or whatever the RequestTimeOut parameter for ADCS is set to in the registry) the miniform shows a somewhat strange behavior after the table is unlocked again. Every input has to be done twice (!). It looks like the connection has been lost and established again, thereby the old form data have not been deleted and the user suddenly finds himself with more than one form active. The only way to escape from this “double-input-behavior” is to log out from the terminal connection and log in again.

My question now: Can this behavior be remedied from within the navision codeunits or is it more “intrinsic” and may be corrected in some further version… ?

P.S.: I have reproduced it with version 3.70 (Hotfix 15)

I never got that type of error when I have timeout from ADCS. If I next week have some spare time I will try to reproduce that problem in NAV 5.0.

Well, meanwhile I’ve tested the situation in 5.0 and I have to say, things are much better there, because after a lock-time greater than 5 sec there are but many errors and warnings in the application protocoll, but the terminal is given some kind of reset after a period of about 69 sec (or whatever is set in the registry parameter “Terminal timeout” under the Navision/ADCS/VT100Plugin key). So by adjusting both values (5 sec and 69 sec) to practical ones, for example 10 sec for lock-timeout and 15 sec for terminal-timeout, one can really work more or less efficiently in a “multi-locking-environment” (of course lock-situations should be prevented from within navision codeunits as far as possible…)

If you want to try it by yourself, here is the code for a sample codeunit to lock the Table “Warehouse Activity Line”:

WhseActivityLine.LOCKTABLE;
WhseActivityLine.FINDFIRST;
IF CONFIRM(‘Release WhseActivityLine again?’) THEN
;

I’ve tested it with “Movements” (point 3 of the miniform main menu). In order to test it, you may have to specify your “Assigned User ID” in a “Warehouse Movement”. I made inputs for bin code and item no., then I locked the WhseActivityLine from another client and typed the movement quantity followed by CR. If the WhseActivityLine is released within 5 sec, nothing great happens, otherwise after 69 sec or so, you can normally continue within the same miniform, the active movement input has of course been discarded.

When installing ADCS according to the manuals, be aware that in order to be able to generate encryption keys for NAS you first have to install the ADCS components (this seems to be an error in the manual)

For some reasons I have to test it with 4.3, too. I will inform you sooner or later…

By now the tests with 4.0 SP3 have been finished and the result is in some respects discouraging. The “double-input-syndrom” seems to be cured, there appears a message on the terminal after 69 sec (or whatever is specified in the registry), but in 4.3 the NAS timeout (5 sec) doesn’t work, i.e., NAS is blocked the whole time during the table is locked. When the table is released again the remaining code is performed (as within a “normal” client) and then the terminal(s) can work again. (Maybe there exists some hotfix for 4.3…)

As a result, one should use 5.0, because in this version other terminals can work, while one is blocked due to table locking (if the other terminals use different tables of course).

Has I have said I never had problems with ADCS timeout. But I’m glad to know your conclusions.