Kevin Cummings's Profile
Agile Angel



I have been working on the Agile PLM space for over 16 years, mostly focusing on data migration and database work. I probably know how the schema works better than most outside of Oracle Engineering, having explored the schema for most of my Agile career
Title Senior Technical Consultant
Company Kalypso Consulting
Agile Version 6.x, 7.x, 8.x, 9.x
  • Per the Import/Export User Guide, “For items in the import file that already exist in the target system, a type mismatch rejection error occurs if the default type assumed by import does not match the existing object in the target system.” So either the subclass in your import file is the default, or it will error out.

     If you want to convert all of the wrongly-typed “Standard Part” items to “Product SKU”, set “Product SKU” as the default subclass for Items in Import, run your file through and then change the setting back to what you would normally want. I am not 100% sure this will work, but I think it is worth a try.

    • 6 answers
    • 0 votes
  • Agile Angel Asked on April 10, 2019 in Product Collaboration.

    So far as I know, there is no limit on the number of values you can have in a list. But at some point, you (or the business) are just being ridiculous. Since you can only display 2500 or so, if you have 20K values, the users won’t ever be able to see all of them.

     Yes, a cascade list (with major groups as the first level, maybe minor groups as the second level, and with the actual values as the third level) will help users wade their way through things.

     Note that each level of a cascade list only contains the list values linked to the level above. So although you will end up with more than 20K list entries, they will be far more organized than to have 20K entries all at the same level.

    • 2 answers
    • 0 votes
  • Role assignments are listed in the USER_ASSIGNMENT table where CLASS = 11640 (group = 11885, site = 11760). USER_ID links to AGILEUSER.ID and then you get the name of the role (only where CLASS = 11640) from NODETABLE. If roles are granted through the user group, then you need to link through USER_ASSIGNMENT to the group, and then to the roles which it possesses.
     Although the “Share” tab does show roles, it does not apparently link to USER_ASSIGNMENT. According to the admin guide, it is “automatically populated, and does not have fields or properties”. So I have no idea how or under what conditions it is populated.

     A query to list all user roles would be :
    select u.loginid, u.first_name, u.last_name, n.description “ROLE”
     from agileuser u, user_assignment ua, nodetable n
     where ua.user_id = and ua.objectid = and ua.class = 11640
     order by u.loginid, n.description;

     If you know the name of the PPM role that you need to know who has, add “and n.description = ‘<role name>’ ” to the where clause, and it will only show you those users who have that specific role.

    • 2 answers
    • 0 votes
  • Never mind, I found the answer. The other-then-agile user that you supply the name and password to AUT as the “sys” user *must* have privileges to login “as sysdba”. I was using SYSTEM, and that default Oracle account does NOT have sufficient privileges to do so (by design). So you really need to actually use the SYS account when running AUT or else make sure to assign the SYSDBA role to the account you are using.

     Oracle document 2110968.1, on the support site.

    • 1 answers
    • 0 votes
  • So this *only* affects users who are logging in using LDAP credentials? And after restarting the Agile application service, it doesn’t happen for a while? Is there any evidence of a specific period of time that it takes for this to happen?
     I would open an SR with Oracle. This should not be happening, obviously, but whether it is an issue with LDAP or within Agile, I do not know. And that a restart of Agile fixes it means that something is good (for a period of time) and then it goes south. It is usually that LDAP users always have problems (something is wrong with the link to the LDAP server) or they are always good.

    • 3 answers
    • 0 votes
  • Agreed with both Arif and madhusudanas, this is usually an issue with trying to reference something that isn’t there. And Averify is a very good first step to take. If you are not already running it once a month on your database (at a minimum), then start doing so.
     What do the PXs do when a task is complete?
     A “Node 0” error usually means that somehow a null or zero ID value is returned, and so when that ID is then used to try and get something else, you get the error.

    • 3 answers
    • 0 votes
  • Agile Angel Asked on March 23, 2019 in Product Collaboration.

    The REV table holds affected items. REV.ITEM links to ITEM.ID for the item number, and REV.CHANGE links to CHANGE.ID for the change number. Note that REV.RELEASE_TYPE is the life cycle, and links to NODETABLE.ID to get the text value. If you are using Sites, REV.SITE links to SITES.ID, otherwise it is always zero. The latest revision has LATEST_FLAG = 1, and released ones have RELEASED = 1.

    • 3 answers
    • 0 votes
  • Agile Angel Asked on March 12, 2019 in Webservices.

    If you do not specify the subclass of a part, then you cannot update P3 attributes. You have specified the class of the item, but not the subclass. Because it does not know which subclass configuration to check against, you get an error. You do have the correct attribute ID for P3.List36, but it has no idea which configuration to validate against.
     Also note that as of PLM, yes there is a P2.LIST36 attribute (ID=2000018794, AKA LIST66).

    • 1 answers
    • 0 votes
  • Agile Angel Asked on January 30, 2019 in Product Collaboration.

    So you see duplicate values when you are trying to select a value for the attribute from the drop-down list. Do you see them when you check on the list in the Java client?

     Look at the database, and see if they actually exist. It is possible that some have a trailing blank or something like that, making them not really a duplicate (although it certainly looks like it). In the Java client, find the list parent ID for the attribute. Then execute the following query :
    select entryid, ‘<‘ || entryvalue || ‘>’, langid, active from listentry where parentid = <the value you found> order by entryvalue, langid, active;

     This should show you if there really are duplicate values. Note that ACTIVE tells you the status of the value itself – 0 = enabled, 1 = disabled (cannot be selected), 2 = deleted (cannot be seen). You can then set the “duplicate” ones as either disabled or deleted in the Java client (open the list itself, and modify as needed), and things should be good. I would recommend setting them as deleted.

    • 4 answers
    • 0 votes
  • Agile Angel Asked on January 29, 2019 in Product Collaboration.

    The schema does not prevent duplicate values in the table, as the index is on the parent list ID, the ID (and not the text) of the list value itself and on the language ID. Are you seeing the duplicates when you try to select a value for the attribute?  Or when you view the list itself? Note that since Agile allows multiple languages to be used, each one has a distinct value since whatever the string value is would/could be different in each language.

     When you manually enter the list values using the Java client, it does check whether you are entering any duplicate values. How did you upload the list of values? Are some of them “deleted”, as those would not be visible to users anyway.

    • 4 answers
    • 0 votes