Different inactive index issues are caught in different ways.

CAN-FIND statements that use an inactive index. The statement returns FALSE if a query is made using an inactive index and returns no error.

FOR EACH...WHERE.. and FIND...WHERE... when an inactive index is referenced, return a run-time error:
DEFINE TEMP-TABLE <temp-table1 name > LIKE <table2 name>. If table2 contains an inactive index, the compiler returns:

This is expected behavior. 

CAN-FIND is a function and returns TRUE or FALSE only.

FOR EACH...WHERE and FIND...WHERE do not raise compile-time errors for inactive indexes for two reasons:

1. The inactive index should be activated by the time the code is executed as part of the deployment proceedure.
2. The code may be run against a different database where the index is activated.

Once a DEFINE TEMP-TABLE statement is compiled, its definition is set. Its definition cannot change at run-time. For this reason, the inheritance of an inactive index is caught at compile-time. 

The -noinactiveidx startup parameter tells the compiler not to use an inactive index when it evaluates the index to use for a query, unless USE-INDEX is specified.
When USE-INDEX is specified, it gives a very clear instruction to the compiler which index to select. By specifying USE-INDEX, the compiler does not need to evaluate an index to use, as the developer has explicitly provided one for the required sorting and bracketing needed. 


 

Progress Article:

 How to stop compiler selecting inactive indexes?