Error 16488: Index of Table is Not Active

KMoody

Member
I added an inactive index (DATE-PART-LINE) online for a table (INVHIST). I then compiled programs that used INVHIST but didn't reference DATE-PART-LINE. When I ran those compiled programs, I received the following error:

Index 'DATE-PART-LINE' of table 'INVHIST' is not active. (16488)
  1. Why would the program throw this error if it's not using DATE-PART-LINE?
  2. Programs compiled before I added DATE-PART-LINE didn't throw an error when they ran after I added the index. Why?
 

TomBascom

Curmudgeon
“If it is not using…” is an unsupported assumption that seems to be false.

You should be able to determine where the unexpected usage is by compiling with the XREF option.
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
Your OE version may be relevant here.

According to the error, the index was active at compile time but was inactive at run time. Prior to OE 11.x, index status was stored in the field _index._active. With the introduction of multitenancy and multiple storage objects per table/index, index activation status is now tracked at the storage object level (_storageobject._object-state) rather than at the index level. According to this article, _active is now always true after an index is added. It is possible your release has a compiler bug and it is still looking at the old field (_active) to determine index activation status.

Why would the program throw this error if it's not using DATE-PART-LINE?
A program doesn't have to reference an index explicitly in order for the compiler to select it to resolve a query.

Programs compiled before I added DATE-PART-LINE didn't throw an error when they ran after I added the index. Why?
Because for static queries, index selection is done at compile time and the selections are in the r-code. The compiler can't select an index that doesn't exist yet. Those .r files don't throw an error about the inactive index because they don't try to use it.
 

KMoody

Member
“If it is not using…” is an unsupported assumption that seems to be false.

You should be able to determine where the unexpected usage is by compiling with the XREF option.
A program doesn't have to reference an index explicitly in order for the compiler to select it to resolve a query.

You're right! According to the XREF information, the program tried to FIND an INVHIST record using the new index. I didn't explicitly choose that index (USE-INDEX), but the program did.

Your OE version may be relevant here.

According to the error, the index was active at compile time but was inactive at run time. Prior to OE 11.x, index status was stored in the field _index._active. With the introduction of multitenancy and multiple storage objects per table/index, index activation status is now tracked at the storage object level (_storageobject._object-state) rather than at the index level. According to this article, _active is now always true after an index is added. It is possible your release has a compiler bug and it is still looking at the old field (_active) to determine index activation status.
I'm using OE 11.7.5, for the record.

Thank you both!
 

KMoody

Member
Yes, we might need to update.. I was hoping the -noinactiveidx startup parameter could prevent this, but it doesn't seem to help in this case.
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
The referenced article says that up to 11.7.5, the Data Dictionary doesn't check index activation status properly. It wouldn't surprise me if the compiler has the same bug. I think you have a good chance of resolving this by updating.
 
Top