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
  • AML data starts with the MANU_BY table. AGILE_PART is the ID of the item. MANU_PART is the ID of the manufacturer part number in MANU_PART, where MANU_ID is the ID of the manufacturer for the part (MANUFACTURERS).
     The CHANGE_IN/CHANGE_OUT is a bit complicated, but it works as follows : to get the data for a given revision, get the change IDs for the revision you are interested in and all previously released  revisions (in this case, both ECO and MCO changes). Then look for any row in MANU_BY where CHANGE_IN is zero or is equal to one of that set of change IDs, and where CHANGE_OUT is zero or not in the set of change IDs. This will give you all AML records that were active as of the latest revision in the set.

    • 1 answers
    • 0 votes
  • Any time you get an error like this, it is usually because Agile *always* expects to get a value, but it doesn’t get one. So the first thing I would recommend is to run Averify, as well as check users and check affected items to make sure that they exist. Glad you found the issue!!!

    • 3 answers
    • 0 votes
  • As Steve Jones stated, I have only ever seen the number of affected items affect the speed of how fast an ECO can be released, and never the depth of the BOM. Note that you are not releasing the entire BOM tree of an assembly, but only it’s direct BOM. And this is true for each affected item. How big the direct BOM is can certainly be a factor, but unless sub-assemblies are also included as affected items, BOM in the next level down will not affect the processing of the ECO. I would never put more the 500 affected items on an ECO, and only then if the client has a rather robust Agile environment. I always recommend less than 200. I still remember a client that had a single ECO for a data load that had 7500+ affected items on it. And of course, users just *had* to go look at it every once in a while. And the system would grind to a halt.

     As Paritosh pointed out, environment resources also play a factor. If your environment does not have a very large heap size, you can quickly swamp it when you have a lot of affected items in an ECO, as it has to pull things in, then push something else out to process the next affected item. It doesn’t take a lot of time, but it does take time.

     Showing a screen shot of the exploded BOM tree for 1243 (with numbers appropriately blurred) would be good. Even better would be a screen shot of the performance metrics of your Agile server when you are releasing the ECO. After that, you might have to dig rather deeper into what is going on. Are there a number of required fields that must be checked on?? That can slow things down a bit (even more with large BOMs, because each component must also be checked). But that only applies to the direct BOM.

    • 4 answers
    • 0 votes
  • Agile Angel Asked on September 1, 2017 in Product Collaboration.

    It would appear that to fix this, when a file that is shared between more than 1 revision is checked out, it must first have a new FILES record created and assigned to the current revision that it is linked to. This would then leave everything else alone, but make sure you have a “new” copy to work with. What appears to be happening is that since the file is “shared” (basically the entire file structure is just linked to multiple revisions), when you check it out, it shows up on all revisions as checked out (that is what the attached document indicated). Since it is a shared file, yes, that (kind of) makes sense. And then it leads to your issue.
     The main reason to use the “Reference” setting on the “Copy Files to Rev” smart rule is to save on vault storage (you don’t create a new version of all attachments when you create a new revision). And it is probably intended only for attachments that most likely won’t change (like external or standards documents). But if you have drawings or other attachments that will change for each revision, you are probably better off using the “Copy” or “Copy with Warning” options. That way every revision will at most have it’s own copy of each attachment, and there shouldn’t be issues with how Agile handles things.

    • 2 answers
    • 0 votes
  • Agile Angel Asked on June 2, 2017 in Product Collaboration.

    Import cannot add attachments or modify attachment tab attributes, except when importing a PDX file that contains attachments. Although an aXML file can contain attachments, it will not process them directly for Items, except as part of a Bill of Substance (I think). I have no idea if Import will add a new record when processing an existing attachment, or replace the file and update the attributes.

     FileLoad can load attachments and attributes as Adrian pointed out, but if you run an updated index file with new attribute values through FileLoad again, it will create new attachment records, it will *not* update existing records. Been There, Done That, and removing the duplicates is a PITA.

     So far as I know, a PX to do this would probably be the best way to go about it. FileLoad has no “update” functionality. I have no idea if Import would update things, or simply add a new record and create a duplicate record. Other than manually changing them, a PX is about the only way to do it.

    • 2 answers
    • 0 votes
  • So far as I know, neither has a defined purpose in the development process per se, certainly not at first. But since Agile is used to track the full life-cycle of products, both are there to allow such things to be documented at a minimum, and so that issues, investigations, conclusions and fixes can be reviewed and approved. Deviations track when a product can not be manufactured according to the defined process. Stop Ships track when an issue is identified such that production MUST be stopped until the issue is resolved. It would be rare to see either of these during the development process, but they are often seen during the pilot, production and obsolescence phases for a product.

     So far as the Affected Item attributes, neither Deviations or Stop Ships are intended to alter the revision for the part (if that is needed, you create an ECO and then link the Deviation and/or Stop Ship to it). No idea why Mass is in the Affected Items tab separate from the actual part information, or why it is editable.

    • 4 answers
    • 0 votes
  • Agile Angel Asked on May 30, 2017 in Product Collaboration.

    There are several tables to look at (and ways) to do this. Probably the easiest is :
    select i.item_number, r.rev_number, c.change_number   from rev r, item i, change c
     where = r.item and r.change > 0 and and c.statustype not in (3,4);
    This way you have the item number and any change/revision that is not yet released (the status type is not released or implemented).

     If all you really want is just a unique list of item numbers, then :
    select distinct i.item_number    from rev r, item i, change c
     where = r.item and r.change > 0 and and c.statustype not in (3,4);

     The ITEM_P2P3_QUERY_ALL_REV will work, but you will have to add criteria in the query to pick out just the pending ones. Using the FLAGS attribute from ITEM also works, but I have seen databases where FLAGS is not always up to date (when was the last time you ran Averify on your database??). STATUSTYPE is better than most in always being up-to-date and correct..

    • 3 answers
    • 0 votes
  • It better be in the AGILE_FLEX or PAGE_THREE tables. Nowhere else for it to be.
     Look in the Java client to see the attribute ID for the new attribute. If it is 1534  through 1538, then it is a PAGE_THREE attribute, so look for the value in the DATE31-DATE35 attribute that is indicated for your new attribute.
    If it is > 1538, then it is a flex attribute. Note that not every object to which this flex attribute applies will have a record in AGILE_FLEX. Only those objects that have a value for the attribute will have a record in AGILE_FLEX (why keep a bunch of null records in the table??).
     So put a value into the attribute for some object, save it, and then check PAGE_THREE or AGILE_FLEX for a record with the ID of that attribute (or the ID of the object). That is where you find the value.

    • 2 answers
    • 0 votes
  • It sounds like you are seeing the same problems that Agile PC had when you put more than 500 affected items on a change. I know of a company that put 5000 affected items on a change, and they wanted to know why that change couldn’t be viewed (it froze up the application server, this was back in Agile 8.5 days).
     I am certain Agile PC is better about it now, but given the amount of data you are pulling in for each related item, it can take up a LOT of memory. So if you give the application a larger memory cache, things get better – to a point. If all it was is a memory issue, then you would be done (assuming you had sufficient memory on your server). So there must be other things going on, such as a maximum list size somewhere that is being exceeded. Managing lots of stuff in memory isn’t too hard, but you have to make sure that you don’t overwrite anything that is being used (by you or anyone else). So yes. keep the list up to date on any improvements you can get.

    • 6 answers
    • 0 votes
  • URL attachments have nothing in the file vault. They are simply a text value that you enter into a browser, and then view whatever is on the website. Instead of a file “name”, it is a web address, so there is no content to store in the file vault. The decision was made that the web content would not be stored in the file vault, as it could be rather large. URLs are advised only when the content is pretty static, such as internal company specifications or government regulatory documentation.

    • 2 answers
    • 0 votes