Status: Verified
SYMPTOM(s):
SQL queries fail on specific tables.
SELECT query fails with -219901 error
DELETE statement fails with -219901 error
[Error Code: -219901, SQL State: HY000] [DataDirect][OpenEdge JDBC Driver][OpenEdge] Internal error -20011 (see dsmret.h) in SQL from subsystem DSM SERVICES function dsmCursorFind called from get_rowid_from_Index on for . Save log for Progress Technical Support.
Error Code: -219901
sql trc file shows:
SQL Server return to client:
sqlca contains error: sqlcode = -219901, SQLSTATE = P0000
sqlca message: Internal error -20011 (see dsmret.h) in SQL from subsystem DSM SERVICES function dsmCursorFind called from get_rowid_from_Index on for . Save log for Progress technical support.
The internal error is stated as: static final int DSM_S_NO_SUCH_OBJECT = -20011 ; /* omFetch called for an object that does not exist in the database. */
SQL Server log file shows the following:
SQL LOG Section Started at 20081106_141140
SQL Environment Variable Settings:
CLASSPATH=UNDEFINED
SQL LOG CONFIGURATION
STATEMENT
SQL LOG FILE MAXIMUM SIZE: 500000000 Bytes
SQL SERVER ID: 134
20081106_141158 6984:
Setting Cursor for SQL Statement: SELECT *
FROM PUB.tablename
20081106_141158 6984:
Returning from sql_fn() with code: 0
20081106_141158 6984:
Preparing SQL Statement: SELECT *
FROM PUB.tablename
20081106_141158 6984:
Returning from sql_fn() with code: 0
20081106_141158 6984:
Describing SQL Statement: SELECT *
FROM PUB.tablename
20081106_141158 6984:
Returning from sql_fn() with code: 0
20081106_141158 6984:
Opening SQL Statement: SELECT *
FROM PUB.tablename
20081106_141158 6984:
Returning from sql_fn() with code: 0
20081106_141158 6984:
Describing SQL Statement: SELECT *
FROM PUB.tablename
20081106_141158 6984:
Returning from sql_fn() with code: 0
20081106_141158 6984:
Fetching SQL Statement: SELECT *
FROM PUB.tablename
20081106_141158 6984:
Returning from sql_fn() with code: -219901
20081106_141159 6984:
Closing SQL Statement: SELECT *
FROM PUB.tablename
20081106_141159 6984:
Returning from sql_fn() with code: 0
20081106_141159 6984:
Freeing Cursor for SQL Statement: SELECT *
FROM PUB.tablename
20081106_141159 6984:
Returning from sql_fn() with code: 0
FACT(s) (Environment):
Using dbVisualizer 6.0.9 to access the tables via ODBC
sqlexp fails with the same error.
UPDATE STATISTICS for the Table, Column and indexes does not change the behavior.
4GL queries against the tables (that are failing with SQL92 statements) to read or modify data are successful.
Can perform a SELECT against some fields in the table, just not all fields in the table.
Incremental .df's have been applied to this database over the past few months.
10.1B0325
Windows
OpenEdge 10.1B
CAUSE:
Index information in the schema used solely by the SQL92 engine is mapped to the wrong index. The "associate object" for the table is wrong in the schema.
FIX:
Set the "associated object" for the table to be consistent with the primary index for the table as seen from the 4GL side.
Sample code:
ALTER TABLE PUB.<tablename> SET PRO_DEFAULT_INDEX <primary index as specified on the 4GL side>;
COMMIT WORK;
You have to commit the statement to update the schema appropriately.
SQL92 will recompute the table CRC but the CRC should not change since the "primary index" is not part of the CRC. The additional effect of the statement above, that the "associate object" for the table will be set to the object id for the index. This his how SQL gets the index to use for a table scan.