What are common causes for error 893 and error 9874

What are common causes for error 893 and error 9874
Troubleshooting 'SYSTEM ERROR: strent request for more than 32K. (893)'
Troubleshooting 'SYSTEM ERROR: strent request for more than 64K. (9874)'

First, determine if this strent request error occurs on the database side or the client side. If it's database, the error should appear in the database log file, if it's client side shouldn't.

Alternatively, locate the protrace file that should have been generated at the time of the error which will typically include "strent, strentd" in the stack. This will also show the executable name used, and thus on which side the error occurred:

• _mprosrv indicates it's the database side.
• _progres, _proapsv, prowin32 are all client side.

When the strent request is on the database side:

This usually means there are too many queries active/open at the same time in the application. Each remote server keeps track of all its clients' queries (be it static or dynamic) in an area which cannot exceed:

• 64 KB in 64 bit products (error 9874)
• 32 KB for 32 bit products (error 893).  

A very common cause for this issue is that dynamic queries or buffers referring to database tables are not cleaned up properly. For further information refer to Articles:

•  Managing Memory within the ABL? 
•  How to troubleshoot "Attempt to define too many indexes" errors for OpenEdge clients ?  
•  How to check for leaked dynamic objects programmatically? 
•  How to detect ABL Memory Leaks with Dynamic Objects Logging  
•  Detect PASOE memory leaks with Dynamic Objects Logging  

Having too many database queries active at the same time can be triggered by client-side issue (see below), or by just having too many clients per server process. In the latter case, re-balance the database configuration to lower maximum number of clients per server (-Ma) and increase maximum number of servers (-Mn / -Mpb).

When the strent request is on the client side:

• Not cleaning up dynamically created objects. In particular, this applies to  dynamic buffers, queries and temp-tables.
• Not cleaning up persistent procedures with buffers/queries when they are no longer needed.
• Too many queries being left open on temp-tables. (this is much the same as a database side occurrence of the error)
• In older versions of Progress, old instances of a query weren't closed automatically when you open the query a second time. They had to be closed manually before the second open was performed.

This condition left unresolved can lead to the server crashing and possibly a DBDOWN. Refer to Articles:

•  Error 893 or 9874 when using dynamic queries  
•  Remote server crashes with client error 438 and error 49  
•  Remote server crashes with error 9874 or 893 - Client error 2659  

Progress Article(s):

 Clients connected to dead remote server process cannot be disconnected