8.11 to 9.1 Index Question

[leggleston]

We are upgrading from 8.11 to 9.1 and outsourcing the retrofit effort. During the assessment, we were informed that for every custom index we've added on a JDE table, that index will need to be reassigned everywhere we've used it.

Example - JDE Table had index 1, 2 and 3. We added index 4 in 8.11 and used it in custom report R56ABC. In 9.10, JDE added a new index and the custom index gets pushed to 5.

Typically I don't think this has been an issue during past upgrades, however, we are being told that our custom index will not be picked up on R56ABC since it referenced index 4 and doesn't know about index 5, as it was re-numbered.

This is an issue for C functions, but for reports and apps?? Any guidance would be significantly appreciated as time is of the essence.

 

[DBohner-(db)]

Lee,

Yes, that can be a contention with Upgrades (and it would be nice if Oracle addressed it).

In the Table's definition, each index is assigned a value 1-> n, as you are aware. Each of those indexes identify the keys that E1 uses for building Fetches and ER Data Selection. ie...

The contention is that the ER contains the 'legacy' numeric value of the original table definition, not the new index keys provided by Oracle. Index 2 was keys B, D & E an is now A, B & D... The ER may validate - but you could end up with errors, strange results or... let's not go there.

Simply adding the custom indexes to the tables is only half the resolution. You still have to fix the ER in every application, UBE, TER, NER and in every function.

Potential fix - is to use the XML Export Process to resequence the Keys, to fit what was legacy and what Oracle added. NOW - that has two issues. Anything that Oracle created with the new keys will be broken, though customizations will, now, work.

To fix for long-term, you might append your indexes, do the XML Export process, set the new Index Keys to something Oracle won't overwrite and re-import. I haven't tried it - but it could future-proof for you next ESU and/or Upgrade.

Best practice will be to retouch all the customized objects, and 'simply' repoint the ER to use the re-addressed Custom Indexes.

Good Luck, buddy

(twas nice seeing you at Collab)

(db)

 

[leggleston]

Thanks Dan - that's what we were looking for (well, not exactly, but that's the truth).

Good seeing your too

 

[DBohner-(db)]

Here you go ...
Found it - Oracle's "Real Answer" to Custom Index, and how to avoid future impacts:

E1: TDA: Custom Indexes on EnterpriseOne Table and Applying ESU with Indexes [ID 648417.1]

Basically, when you create new indexes, create up to 'Ten' dummy indexes, before you create the legitimate one you will want to keep. This will set the Index ID Inclemently higher than what Oracle 'might' use in a future ESU or Release. Then, Delete the 'dummy' indexes...

Though this doesn't resolve your current issue - it will help you for future-proofing your next set of ESU(s), Update(s) or your 10.0 Upgrade...

Also review:
E1: TDA: Steps to Create a New Index on an EnterpriseOne Table [ID 634520.1]
- Sorrowfully, the above document does not provide a hint regarding Index Collisions during Upgrades and ESUs.

Sorry, buddy!

(db)