Salesforce

Client fails with error 2733 when running a FOR EACH query with an OR operator

Printable View
« Go Back

Information

 
TitleClient fails with error 2733 when running a FOR EACH query with an OR operator
URL Name000055853
Article Number000171504
EnvironmentProduct: OpenEdge
Version: 11.2.x, 11.3.x, 11.4.x, 11.5.0
OS: Windows
Question/Problem Description
Client fails with error 2733 when running a FOR EACH query with an OR operator.

Query being executed is similar to the following: 
FOR EACH <table-name> WHERE <field-name> = 5 OR <field-name> = 6 NO-LOCK:
  /* in the query 'field-name' is the same Int64 field */
END.
When running the query the client session crashes immediately.  The database log for single-user session contains:

16:03:11.579 P-1352 I ABL : (451)   Single-user session begin for <uname> on CON:. 
16:03:11.579 P-1352 I ABL : (15321) Before Image Log Initialization at block 123697  offset 6164. 
16:03:11.599 P-1352 I ABL : (7129)  Usr 0 set name to <uname>. 
16:03:11.856 P-1352 F ABL : (2733)  SYSTEM ERROR: Bad query request 
16:03:11.906 P-1352 I ABL : (334)   Single-user session end.

If clients connect to database using TCP/IP, the remote server process that crashes with 2733 and all clients connected to that remote server terminate:

SYSTEM ERROR: Bad query request (2733)  
Disconnect from server; database is being shutdown. (2659)

The resulting protrace file on Windows with pdb files in place contains:

Call Stack:
Address           Frame
000007FEFCC3940D  000000000027E1F0  RaiseException+3D
000007FEE55427A7  000000000027E220  utcore+27
000007FEE4EE980D  000000000027E260  drexit+27D
000007FEE4EDBA8F  000000000027E2E0  msgout+32F
000007FEE4EDC19E  000000000027E320  msgb+1EE
000007FEE4EDCDDC  000000000027E700  msgn+6C
000007FEE53EBFF2  000000000027E7A0  qrTmpClose+252
000007FEE53EC9F7  000000000027E850  qrTmpFind+577
000007FEE53ECBED  000000000027E950  qrTmpInsert+12D
000007FEE53EA93F  000000000027E9A0  qrDupsGet+EF
000007FEE53E935E  000000000027E9D0  qrNext+18E
000007FEE4F53448  000000000027EA50  dbqry+F8
000007FEE519DF57  000000000027EA80  proTablePartitionNameGet+137
000007FEE51A0195  000000000027EC30  profnd+165
000007FEE4EEE933  000000000027ECB0  fdfnd+113
000007FEE5205BCB  000000000027ED50  bfFindRow+34B
000007FEE52928D1  000000000027F440  rnbfnxtDoit+421
000007FEE5294CAC  000000000027F520  rnbfnxtBody+43C
000007FEE5295CD8  000000000027F550  rnbfnxt+218
000007FEE5258220  000000000027F600  rnexec_entry+2D0
000007FEE5266A4A  000000000027F630  rninterpret+3A
...
Steps to Reproduce
Clarifying Information
This issue does not happen in OpenEdge 10.

The error is related to the volume of data being processed at the time:
  • If there are very few records then the client does not crash.
  • With more data returned by the query, the client crashes.
Error MessageSYSTEM ERROR: Bad query request (2733)
Defect NumberDefect PSC00322775, PSC00321705
Enhancement Number
Cause
The intermediate nodes of the b-tree built to keep track of rowids already seen when processing a query with OR terms in the where clause were not being split correctly.  They were being split as though they were leaf nodes containing only rowids (8 bytes) rather than "rowid key value" plus offset (16 bytes) into the srt file that contained the block that covered that range of rowid values.

 
Resolution
Upgrade to OpenEdge 11.5.1, 11.6.0 or later. Where splitting intermediate nodes is determined the size of an index entry rather than the leaf block.

When connecting to the database over a network, the fixed version needs to be installed on both client and server machines.
Workaround
1. Specify an index on the query with USE-INDEX <index-name>.  For example:
  
FOR EACH <table-name> WHERE <field-name> = 5 
                         OR <field-name> = 6 NO-LOCK USE-INDEX <index-name>:
  /* in the query 'field-name' is the same Int64 field */
END.

2. Setting -TB to 16 (or 32) in the client-connection parameters has been shown to alleviate the issue.
Notes
Due to the nature of this defect, it can manifest with different sets of symptoms.
In other confirmed cases, it triggers an error "SYSTEM ERROR: I/O error 0 in readfrmb, ret 0, file 7(srt*), addr ... . (290)" 

Progress Article: 

 Client crashes when doing FOR EACH query with I/O in readfrmb (290) error
Keyword Phrase
Last Modified Date11/20/2020 7:28 AM
Powered by