Index fails to generate

[Crazy_About_JDE]

Hello, all-- I have a problem with a new index not generating.

There were 26 indexes for F42119. I added a new one (PA8,SHAN,IVD,LTTR,PRP2,SRP1,SRP2) and checked in the object. After generating the table’s indexes and receiving a Success message, the last index that appears on the system is F42119_32--but the properties are for the last index (#26) in Table Design Aid that was there before I added mine. I have checked all the indexes; none has the properties of my new index.

Why would E1 not generate my index?

Notes:
1. I added the same index to F4211 and it worked fine.
2. I did this after hours when I had a dedicated system.
3. The file naming is misleading, because several numbers are skipped, like 5, 6, and 7:

F42119_3 *FILE PRODDTA LF
F42119_30 *FILE PRODDTA LF
F42119_31 *FILE PRODDTA LF
F42119_32 *FILE PRODDTA LF
F42119_4 *FILE PRODDTA LF
F42119_8 *FILE PRODDTA LF
F42119_9 *FILE PRODDTA LF


Thank you in advance for any guidance!

-Tim

 

[Gergely_Pongracz]

Hi,
try checking the spec tables F98712 and F98713 in the appropriate central object data source. The structure is quite simple - try to see if yours is correctly there.
Don't worry about the skipping numbers - it happens when you delete a wrong one (or JDE programmers did).
Regards
Gergely

 

[Gary P]

Whenever I make a change to a table, I find that generating that new change almost never takes effect. I verified through debug logs that it's as though you never made the change and checked it in. I think the table specs are cached, so you need to notify your memory and tell it you've made an update. Here are some suggestions:

-Exit JDE completely and restart. You may have to tweak by checking out/get the newer specs after you do this.

-Use Pastuhov's OneWorld Debug Log Commander and flush your caches. I don't know if this is free or not since it was here when I arrived.

-Edit your jde.ini file and tell it not to use caches (very good option if you're a developer). This will fix similar issues with other specs as well and keep you from having to restart. Alas, I don't remember how to do this option.

 

[Crazy_About_JDE]

Thank you for writing, Gergely. Yes, the new index appears in both the header F98712 and the detail F98713. Here are the records from the detail file:

TLOBNM TLINID TLDESC TLOBND TLCMPI TLJDEVERS TLMRGMOD
F42119 33 PA8,SHAN,IVD,LTTR,PRP2,SRP1... PA8 1 B7334 A
F42119 33 PA8,SHAN,IVD,LTTR,PRP2,SRP1... SHAN 2 B7334 A
F42119 33 PA8,SHAN,IVD,LTTR,PRP2,SRP1... IVD 3 B7334 A
F42119 33 PA8,SHAN,IVD,LTTR,PRP2,SRP1... LTTR 4 B7334 A
F42119 33 PA8,SHAN,IVD,LTTR,PRP2,SRP1... PRP2 5 B7334 A
F42119 33 PA8,SHAN,IVD,LTTR,PRP2,SRP1... SRP1 6 B7334 A
F42119 33 PA8,SHAN,IVD,LTTR,PRP2,SRP1... SRP2 7 B7334 A

 

[Crazy_About_JDE]

Thank you for writing, Gary. In this case, the problem is occurring on the iSeries server. The index appears correctly in my local specs.

Any ideas for the server side of things?

 

[pkonings]

1. Does the JDE database proxy user has the correct rights for dropping and creating indexes? Have a look in jde.log when trying to re-generate the in dexes.
=A0
2.
=A0
What is the size of the table for which you are adding=A0this new index? In case huge number of records a max. execution=A0timeout could prevent you f rom completing the creation of this new index. Or lack of (temporary) space within the given AS400 library.

3. Is the new index having unique constraints defined as well, if so are yo u sure you do not have duplicate values in F42119 for this index.
=A0
4. Last capture and=A0review the AS/400 job log for the given process to kn ow why it is failing...
=A0
5. Alternative is to use sql statement to create new index by using IBM Cli ent Access, for example by running MS Access pass through query... Or AS400 command to create the new logical.
=A0
Rgrds, Peter.

 

[Gary P]

I've had the same issue. The specs appear fine locally, but when I'd try to generate, it was as though I was sending the old specs. When I set up a debug, I could see that JDE was sending the old specs in the generate command. The cache can get pretty tricky, I'm just saying that my issue may be yours, while you may have a different issue.

Regardless, I think we can all agree that a debug log would be beneficial. Can you try and generate the index on your local machine while having a debug log running? Then if you can isolate the SQL statement for that table, we can see what JDE is telling the iSeries, and what the iSeries is saying back.

 

[Alpinist]

I've been experiencing this as well and I'm wondering about the previous comment made in regard to

"the new index having unique constraints defined as well, if so are you sure you do not have duplicate values in F42119 for this index."

What does that mean exactly? I'm using DCT/VR01 as a new index to F03B11. I definitely have duplicate entries for this combination of 2 fields. Is that a bad thing?

I'm on E900, 8.98.
Thanks,