I run the same warehouse registration operation on two Navision 3.70 clients simultaneously. Sometimes it leads to a hang - both clients don’t prîcess any messages and have white screens. In SQL Enterprise Manager → Process Info window I see such an info: client1: spid=56, status=sleeping, open transactions=0, command=awaiting command, wait time=0, wait type=not waiting, wait resource=…, blocked by=0, blocking=1 client2: spid=55, status=sleeping, open transactions=1, command=execute, wait time=0, wait type=miscellaneous, wait resource=…, blocked by 56, blocking=0 This info is regularly refreshed but it is the same all the time while the clients are hanging. After an hour of hanging I kill the process 56 manually via the SQL EM “kill process” method. The client2 proceeds with transaction and finishes it succesfully. The client1 either can get an error message: “Internal error 1247 in unit 19…” (What does it mean?) and then terminates, or can get a server connection lost error message and then, after we reconnect to server, we can gather the log information via the Form 150020 Client monitor for both clients and 150024 Client monitor (Multi-User) (referred by the “Performance troubleshooting guide.pdf”). Log investigation leads us to an error in the “SQL Error” field: "[Microsoft][ODBC SQL Server Driver][DBNETLIB]ConnectionRead (recv()) , occurred at the hang time displayed in the “Time” field. What does this error mean? Also I run the SQL Profiler to track this issue. Profiler’s trace investigation leads us to an “Lock:Deadlock Chain” event: “Mode=RangeS-U, IndexId=1, Table= Warehouse Activity Line”. We also get a “Lock:Deadlock” and “Exception” event for process 56: “Error=1205, Severity=13, State=50” (process 56 was chosen as a deadlock victim). So, at the hang time it is a deadlock and process 56 must be stopped, its transaction rollbacked, client1 get a deadlock error message, process 55 lock necessary recources and finish its transaction - so no one hangs. But it is not! The clients are still hanging! How is it possible? If it is a deadlock then SQL Server must resolve it correctly! But it is not! I guess, process 56’s transaction is not rollbacked somehow and it still lock recources, so process 55 can’t proceed. How is it possible? Any help or suggestions on this issue willl be very much appreciated. Thanks in advance.
it’s cause of irregular code - records modification and insert order. Debuging NA posting routines is terrible thing [xx(] I had similar problem sometime ago. I had solved it by adding dumy code before problematic code zone. Code simpy gets record and changes value. It can be any table, any field. Modification locks record unti transaction end and another process can’t be processed unlit commit of first. It’s works like semaphore or mutex. It can cause lower perfomace, but solves deadlocks. No much elegance but works 