R
Rob Fitzpatrick
Guest
You could: Step through the code for that screen in the debugger, watching promon and the tables/buffers that are in scope in the debugger. Run the code with -clientlog client.log -logentrytypes QryInfo:3 (or equivalent LOG-MANAGER attributes) and look in the resulting client log for queries on that table; you'll find it unless it's FIND statement. Prior to the second client entering that screen/querying that table, enable Database Client Request Statement Caching (aka Client Statement Caching; promon R&D, 1, 18, 1, 1, usr#). You should then be able to read their current ABL call stack frame info from their _connect record or from promon R&D, 1, 18, 7, usr #. This should give you the program name and line number (from a COMPILE DEBUG-LIST) where the second client blocked. If this is production, don't forget to turn off Client Statement Caching when you're done. 
Do the above via ProTop, if you use that. Run a COMPILE LISTING of the program and look at the buffer scope info. Look through the code for queries on that table that don't explicitly specify a lock strength (i.e. NO-LOCK or EXCLUSIVE-LOCK). Static queries without a lock strength will default to SHARE-LOCK, unless the client was started with -NL. Since it sounds like you can reproduce the problem in the second client right at the point of the query you're trying to find, I'd probably start with the third suggestion above. It will give you the line number of the query.
Continue reading...
Do the above via ProTop, if you use that. Run a COMPILE LISTING of the program and look at the buffer scope info. Look through the code for queries on that table that don't explicitly specify a lock strength (i.e. NO-LOCK or EXCLUSIVE-LOCK). Static queries without a lock strength will default to SHARE-LOCK, unless the client was started with -NL. Since it sounds like you can reproduce the problem in the second client right at the point of the query you're trying to find, I'd probably start with the third suggestion above. It will give you the line number of the query.Continue reading...