To see how to create an index file, look in the Import/Export User Guide for the chapter/appendix on using FileLoad (it is usually the last one). It explains everything you need to know about using FileLoad and creating index files.

FileLoad is intended to allow large numbers (> 100) of attachments to be processed at one time. Note that if index files are greater than 10K records, things can sometimes crash without much explanation. As Adrian noted, there are significant differences between using FileLoad from the Java client and from the web client (I always use the Java client version). Make sure the users understand this and know how to create index files correctly. The major performance hit is usually from having to move the files from wherever they are located to the Agile file vault – when moving multiple GB of files around, the network can slow down a LOT. So I usually recommend that the files to be attached be local to the server on which DFM and the file vault reside, thus removing the network from the equation.
 The most efficient means of importing large numbers of attachments is to create a read-only custom vault, put the files there and use the INPLACE option in the index file. Doing this eliminates the need to move the files around, they are already where they will need to be. So all FileLoad has to do is create the database records that link the file to it’s intended object. Note that this can only be done using the Java client, and it does require some up-front setup (moving the files to the read-only vault), but Fileload can easily attach 5K files/hour using this option.
 But seriously, letting 10’s (or hundreds) of users run FileLoad (possibly at the same time) probably won’t be very good for performance. To run it efficiently requires a fair amount of setup and planning. It would probably be better to assign responsibility to run FileLoad to one or 2 folks (maybe a small group of folks), have other users request to have files attached, and then have the designated folks make sure things are ready and schedule when things will run. For 10-20 files or less, it is just as easy to attach them manually from the web client as it is to create the index file, get the files where they need to be and run FileLoad.

If you have 100’s of thousands of items and BOM to load, you are far better off using DataLoad. It is more efficient and also allows the data to be validated before you try to load it. It also does not go through the application server but talks directly to the database server. But you would also be best served by running DataLoad during off-hours instead of during the middle of the day, as you also have to run a number of scripts afterwards that will burden the database server significantly. Then again, DataLoad is not a customer-facing tool, so you might have to engage the services of a consultant who is experienced in using it, to assist *you* in using it.
 Note that Import runs on the local server of the user that starts it, but it does a LOT of talking to the application and database servers. Load balancing of the application and database servers will take care of them, but you might still be constrained by the performance of the local desktop/laptop of the user running Import. If you use DataLoad, you can collect all the data together, process it and get it loaded pretty quickly, all from one server that can be dedicated to that task. Again, using DataLoad is quite different from using Import, and so the planning in each case will be quite different.
 If you will have users only importing 10s-100s of items and BOM at a time, Import is fine. As Adrian noted, make sure that users have correct privileges (you may want to create an Import role and assign it all the correct privileges). Having them widely separated won’t make a difference. I assume that your application and database servers are already using load-balancing, so other than making sure network bandwidth is good, there is no reason to assign a specific cluster of nodes for Import.

No, do not alter the roles in any way. Simply remove the roles from the users (easier to do that from the roles than from the users, as there can be LOTS more users than roles). What you end up with is that every user only has the minimal Read-Only and Discover roles that are needed to find things and look at them. If you later want to add back specific roles, you can do so, but since you only want users to look at things, Read-Only, My Profile and a role that allows them to discover things are all that is needed.

You would modify the following settings in averify.properties :
averify.dest.jdbc.url = jdbc:oracle:thin:@<server name>:<instance port>/aglstg01
averify.dest.tns.name = aglstg01
averify.dest.oracle.home = /app/oracle/product/11.2.0/db_1

 Note that you would still have to specify the server name and Oracle instance port number (usually 1521) in the above.  I don’t think you need to worry about the path, Averify knows how the Oracle directories are set up and uses the definition for averify.dest.oracle.home to run stuff. Also note that I am assuming that “aglstg01” is defined in tnsnames.ora so that the specification for “averify.dest.tns.name” will work, otherwise just leave it blank.

Don’t mess with the roles/privileges themselves (some of them cannot be disabled). Go to the Roles node in the Java client (Admin tab, User Settings, Roles) and open all those that have to do with create or modify. Go to the User tab on each role, select all users, remove them and you should be good.

Do you want ref-des as well??   The easy answer is to look for any record where CHANGE_OUT is zero, for a specific assembly :
select a.item_number,b.item_number, b.find_number,b.quantity,r.label from item a, bom b, refdesig r
 where b.item=(select id from item where item_number='<assembly number>’) and b.id=r.bom(+) and b.change_out=0;

 However, the above *will* include records for pending changes as well. So if you have a lot of pending changes, the above will not work (at least not well). It will also list multiple lines for BOM records that have multiple values in the ref-des, because those are stored separately instead of as a single string in the DB.
 To really do it correctly, you need to make sure that CHANGE_OUT is zero *and* that BOM.CHANGE_IN references the ID of a released change linked to the assembly. And in order to not have 1 ref-des per line instead of all together (where there are multiple values), you would have to do this as a PL*SQL procedure so that you could collect them together as a single string value. It can get quite interesting when you have 20-30 revisions for an assembly or several hundred ref-des values for a component.

Just about every table in the Agile schema has an attribute named “ID”. it is always a unique numeric value for each record (and actually unique across all tables). It is used to link records in the schema without having to copy text values as key attributes. In ATTACHMENT_MAP, PARENT_ID is the ID from ITEM, or CHANGE, etc. based on the value of PARENT_CLASS (ITEM = 9000,10000, CHANGE=6000,7000,8000,11000,1450).

No. There are no methods to do configuration in the SDK API, and disabling/making an attribute non-visible is a configuration task. Why do it every time a PX runs instead of once in the Java client??  If those attributes are really subclass-dependent, then

Find the ID for the file from the FILES table in the database. Easiest is to look for the file name, but if it isn’t unique, you’ll have to track back through ATTACHMENT_MAP to make sure you are getting the correct ID that you couldn’t pull up. Take the ID