So far as I know, there is no report or search that can do this inside of Agile.
 From the database, however, it can certainly be done. The script below should work (and it should be better indented, but the copy/paste didn’t bring tabs over).

set serveroutput on

declare
  assmID number;
  assmNM varchar2(100);
  compNM varchar2(100);
  frelr number;

cursor csrLBA is select distinct item from bom;
cursor csrFRR is select change from rev where item = assmID and change > 0 order by release_date asc;
cursor csrCAR is select distinct item_number from bom where item = assmID
and change_out=0 and (change_in = 0 or change_in = frelr);

begin
— get distinct list of all assemblies
  open csrLBA;
  loop
    fetch csrLBA into assmID;
    exit when csrLBA%NOTFOUND;

— get the item number for each assembly
    select item_number into assmNM from item where id = assmID;

— get the ID of the first released change for the assembly
    open csrFRR;
    fetch csrFRR into frelr;
    close csrFRR;

— find any items which are current (CO=0) and were added by either Intro or first rev (CI=0 or CI=frelr)
    open csrCAR;
    loop
      fetch csrCAR into compNM;
      exit when csrCAR%NOTFOUND;

      dbms_output.put_line(assmNM || ‘ – ‘ || compNM);
    end loop;
    close csrCAR;
  end loop;
  close csrLBA;

end;
/
show err

Probably because Suppliers and Manufacturers are in different modules (PG&C vs. PC) is the cause of the difference in how they act to making P2/P3 visible. I do find it weird that they would act differently, but I have found other (minor) differences between how 2 separate modules operate, so your mileage may vary (and what I have found is nothing major, although this is one of the more obvious differences I have seen).

The below query will return any subclass for Parts that is disabled :
select id,description from nodetable n where parentid=10004 and exists (select null from propertytable where parentid=n.id and propertyid=40 and value=’0′);

 You can change NODETABLE.PARENTID to 9004 to check for disabled Document subclasses. In most cases, the ID of the User Defined Subclass node for a class is the base ID plus 4, but double-check that rather than assume that it is true for everything.

So the question is more, do you simply want to change the attribute value, or do you want to also make sure that the change is noted by history and the change-control functionality??
 If all you want to do is change the value, it isn’t too hard. Build a table of all the item numbers (NEED_MOD) that need to be affected. Then run the following SQL :
update agile_flex set number1 = <list value ID> where attid = <flex attr ID> and id in (select id from item where item_number in (select item_number from NEED_MOD) );

 But I think Antonio’s suggestion (Groovy script) is much better. At a time when the system isn’t busy (or you can lock everybody out), modify the attribute to *not* be change-controlled, and use a script to make the changes through the Agile server. Then change the attribute back to being change-controlled. You automatically get a history record that way (ALWAYS a good thing) and you also don’t have to look everything up (list ID, attribute ID, etc.). Import would also be a good thing to use, although probably slower.

Also note that no matter how you plan on doing this, TEST IT FIRST in your Development or Test environment. I know the database schema rather well, and even I would not just simply run this in the Production environment. No matter what or how you are going to do this, TEST IT FIRST, so that you don’t accidentally screw things up (Been There, Done That, and had to clean it up). Using SQL to directly modify the database should be your last option, and only used if there is no other way to do what you need done.

Not easily. You would have to get all rev changes, and construct a query along the lines of :
select * from bom where item = (select id from item where item_number='<assembly#>’)
 and change_in IN (0,<all rev change IDs previous and including revision you wish the data for >)
 and change_out NOT IN (<all rev change IDs previous and including revision you wish the data for>);
 There are lots of component item P2 attributes that are commonly shown in the BOM tab, so you would have to get those separately for each component.
 Yes, this is complicated, but the number of records needed to hold a large multi-revision BOM is MUCH less than what you would think, even if the BOM has been modified a lot. And with the indexes that are on the BOM table, it works pretty efficiently.

Not so hard, and yet rather hard.
 All login passwords are stored in AGILEUSER.LOGIN_PWD where LOGINID is the username of the user. But they are always encrypted. And starting with 9.3.2, you could use a number of “better” encryption methods (AES, RSA, etc.) as desired.
 But for today, let’s make this simple. Use the following query to set the password to be “agile987” for the “admin” user account :
update agileuser set login_pwd=’LD0RK6THOLTE9IIBD6RVO40L8L5OA1EK’ where loginid = ‘admin’;

 If you want to use something else as the password, look for the “encryptPwdUtil.cmd” file in AGILE_HOME/AgileDomain/bin directory. You can find specific directions on how to use it in the Admin Guide manual. Also note that running the above utility multiple times in a row with the same plain-text password may NOT return the same result every time.

 Then stop/start the application server so that the new password is read in. The above is not a good method for changing normal user passwords, as it REQUIRES you to stop/start the application server after having made the change in the database.

To see history information for items/manufacturers/mfr parts/etc. (non-routeable objects) look at ITEM_HISTORY.
 For changes/psr/qcr/etc. (routable objects, i.e. those with a workflow) look at CHANGE_HISTORY. Note that PPM routable objects can use CHANGE_HISTORY *and* PROGRAM_HISTORY.
 You can find the values for ITEM_HISTORY.ACTION by using list ID 4456 (LIST_HISTORYACTION). For CHANGE_HISTORY.EVENT_TYPE, use list ID 4457 (LIST_WORKFLOWEVENT).
 Most everything else is object ID values, which you can link to the correct table using ITEM_HISTORY.CLASS or CHANGE_HISTORY.CLASS_ID. NODETABLE comes into into play with CHANGE_HISTORY.PREV_STATUS and NEXT_STATUS. USER_ID links to AGILEUSER, although the full user name is always in USER_NAME, so you don’t need to go get it separately

Log into the Java client. Go to the Admin tab, and open the User Settings node, under which there is an end node named User Monitor. Click that open, and it lists all users currently logged into Agile. The count of user sessions is given in the upper right corner.
 You can send email to users from this node, as well as terminate a session. Unfortunately, I don’t think there is a means of exporting that list of users, but you can certainly take a screen shot and paste that into a document.

Agreed, the Import utility is of no use in this case. It can be used to create changes, but can only update them when one is still at Pending status. After that, Import will not modify a routable object. I won’t describe the following as a “good” way to do this, but it is certainly possible to use SQL*Plus to do this. Note that the Agile Software Warranty used to specifically prohibit doing this under penalty of the warranty being null and void (I don’t think Oracle does this anymore, but……). The schema *is* rather complex, but I am telling you the easiest way to do this.

 I assume that you want to set all these old changes to the same Reason Code value? Note that REASON_CODE is a list attribute, and holds the ID of a single list value.  So find a change has the value you want to set all the others to (if none currently do, create a new change and set it to that value). Use the below query to see the list ID for that value :
select reason_code from change where change_number='<chng num>’;

 Then create a script that contains the following query for each change you want to modify :
update change set reason_code = <ID from above query> where change_number = ‘<old change #>’;
 To generate a script the above can be automated by any number of means, and thus generate a script for a lot of changes fairly easily.

 Stop the Agile application server. Open an SQL*Plus session into the Agile schema, open a spool file, and then run the script. Close the spool file, and log out of SQL*Plus. Then start the Agile application server, wait for it to start, and log in. You should see the new values in all of the changes that were modified. The stop/start of the application server *is* important as it uses a large memory cache, and if the data for an object is in the cache, you will see that rather than what is actually in the database (and therefore, not the value that you just changed).

Do you know which record is causing the problem??  If not, then literally split the spreadsheet into 10-20 record portions and find which one fails. Then continue splitting it up until you have found *the* record which is failing. Then post the bad record here.
 It appears that Import is expecting something but it is getting a null (and not necessarily from the data, although likely – are all required fields filled in??). Without being able to see the data record, we cannot explain what is going on.