Based on the error messages, you are having issues with your delimiters. Make sure that you are consistent in what you use as a delimiter, and that it is specified when you run FileLoad. Comma is the default for the field delimiter, but since it is commonly used in file names and description, I normally use the pipe. But you must tell FileLoad what you are using, as it will not auto-detect. And make sure that you do not have any of the default delimiter values (Attribute Name-Value Separator, for example) in your record because it *will* cause problems when it sees them. You can also leave the “%20” stuff out of the file name, just put a blank in there, FileLoad won’t care.
 And as Adrian said, which version of FileLoad you are using can also affect how it works (the Java client version is much better than the web client version). Find and read the Import Export Guide chapter on FileLoad if you have not yet done so.

It is not quite easy. Attachments are linked to business objects using ATTACHMENT_MAP. PARENT_ID is the ID for the object, and PARENT_C LASS is the class ID, and lets the server know where to go to get other information, if needed. FILE_ID is the ID of the actual file, and can be linked directly to the FILES table. That very same ID is used in the file name in the vault, as well as for which sub-directory it is located in. Agile uses the ID in the file name because it helps in anonymizing the file itself (keeping those pesky engineers from editing it without going through the PLM system) and as a simple unique-ness element. The directory where the file is located can be determined by doing the following : 1) convert the file ID to a string; 2) remove 2 rightmost digits, and zero-pad on left to 9 digits total; 3) file directory will then be “<root>/<digits 1-3>/<digits 4-6>/<digits 7-9>/”.
 An example for a text file would be ID = 3579812. Trim and zero-pad gives “000035798”. So the directory would be filevault/000/035/798/agile3579812.txt.
 If you can get the distinct ID for a file, you can then find it and read/copy it from the file vault. I am not certain that getting that ID is easy to do, as it is not a visible attribute by any means. If the API can retrieve that value, you  should be good. Then again, if the API can get the file ID, it can easily get the file itself for you (see below).
 Note that FILE_ID does not always have a value in the ATTACHMENT_MAP table. In that case, you have to link ATTACHMENT_MAP.LATEST_VSN to VERSION_FILE_MAP.VERSION_ID, and retrieve the corresponding FILE_ID value from VERSION_FILE_MAP.

 All of this depends on being able to query the database directly, get the necessary ID values, and then figuring out the file name and location so it can be copied out. You might be best served by writing a PX that uses the Agile API to do that for you – all you need to do is supply the document number, and it copies the file(s) for the latest revision to a temp directory where it can be opened for review by the web portal.     ???

All properties of attributes (and many other things) are stored in PROPERTYTABLE. This includes what the data type is, what database attribute it is, what the max length can be, what list is associated to it (if a list or multilist attribute, whether it is a required attribute, etc.
 The default value for an attribute can be viewed using :
select p.value from propertytable p, nodetable n where n.description='<insert attribute name>’ and n.objtype=1 and n.id=p.parentid and p.propertyid = 5;

To get a list of the possible attributes (and their ID) for a class, use the following query :
select n.id, n3.id, n3.description, n3.name
 from nodetable n, nodetable n2, nodetable n3
where n.description = ‘<insert class name>’ and n2.parentid=n.id
   and n2.description = ‘Attributes’ and n3.parentid=n2.id;
 Note that all this will get you is the list of attributes available for the given class title/cover page and P2 attributes (P3 attributes are linked to the subclass – the query for the subclass attributes looks a LOT the same, but just starts from the subclass record instead of the class record). All other information about an attribute (whether it is visible, what list is it linked to, what is max length, what is the default value, etc.) can be obtained from PROPERTYTABLE, where the ID from nodetable will be PARENTID in Propertytable. Everything is arranged in a hierarchical mannger, going from base class, to class, to subclass, etc. Most of  the basics in NODETABLE and most other information in PROPERTYTABLE (note I am *only* talking about classes, subclasses and attributes). You need to find out the values for OBJTYPE in NODETABLE (13 is subclass, 1 is attribute, 5 is class), as well as what the values in PROPERTYID mean (15 is the list assigned to the attribute, 10 is the database attribute name, 9 is whether it is visible or not, 2 is data type). To get all this data in a single query is nigh impossible, but that is why PL*SQL was invented – you start with the basic information and add what you need from there into a table.

Agreed, a function is the only way to go in a query. Note that in general you will need to use the correct parent ID for the list you will be processing, and as such I would pass it in as an argument to the function. For most multi-lists, this will work just fine. But you also have to take into account when the attribute has too many ID values assigned to hold in the actual database attribute (they usually have a max length of 765, and so can hold somewhere around 100 values), and so the values are then stored in MSATT. Or when the string of values that is created from the list of ID values exceeds the max length for VARCHAR2 data. But in most cases, those things are not an issue.

Agreed with Danny, relating a document to the BOM of a Part is better than using the Relationship tab. You have better control over which revision the document if good on, and which ones not.
 Also, in Agile, there is no concept of “versions”. An item has revisions, and that is what is released and controls it’s information. Versions are usually considered a subset of revisions, and as such it is not supported by Agile.
 As for attribute history, you can view what has changed (and when, and by whom) in the history tab. In addition, you can make an attribute change-controlled, and so the values are stored for each revision of the part. So if you had a UoM of “KG” for rev A, and then changed it to be “Gram” for rev B, if the attribute is set as change_controlled, when you view rev A you would see “KG”, and when looking at rev B you would see “Gram”. Note that this introduces a fair amount of overhead when changing from one rev to the other, but if you only set a few attributes as change-controlled, you won’t notice.

Okay, more basic info. For each base class (Items, Changes, etc.) there are 5 things that are under it : Attributes, User Defined subclasses, Actions, Lifecycle Phases and Tabs. Under Attributes will be all base page/Page2 attributes. Under Lifecydcle Phases are all valid status/lifecycle values for the base class. Etc. “Tabs” lists the tabs that will show up for the base class. The Tab ID and class value can be used to show the attributes that are in that tab for that class. 
select nt.description,na.id,na.description
from nodetable nt, nodetable na, tableinfo ti
where ti.classid=10000 and ti.tabid=nt.id and ti.att=na.id and nt.description=’Title Block’
 order by nt.description,na.id;
 The above query will list the Tab name, attribute ID and attribute name for all attributes in the Title Block tab for the Parts class. By using the subclass ID and correct tab name, you can get the P3 attributes listed for for each subclass as well. You still don’t know which ones are visible, but you know which ones *can* be in each tab.

Excellent point, abidani. Could they write an SCO against the global site if they are not using Sites in PC???  (I’ve never used sites much).

There is no such role, privilege, feature or capability in Agile  By having such, you are defeating the major reason for using a PLM system, human error or not.
 If it is the latest rev, bite the bullet and change the rev (with a minor rev, like B.1) and make the data right.  If it is a previous revision that has had a subsequent revision that corrected things (or not), you will have to make a note that points out the BOM redlines that apply to that previous rev. Yes, this would be an issue for spares provisioning and such, but such a editing capability could be mis-used far too easily.

Lifecycle IDs are in the REV.RELEASE_TYPE, along with the revision and change that released it. The text values for the lifecycle are found in NODETABLE.
 OBJVERSION is simply a counter for how many times a particular ITEM record has been updated.