You are close, very close.
 Add the following line to your where clause : AND AGILE.ATTACHMENT_MAP.PARENT_ID2 = AGILE.REV.CHANGE
 The PARENT_ID2 attribute in ATTACHMENT_MAP holds the ID of the change that released the revision to which the file is associated. Including the above in the where clause will make sure that you only get files linked to the latest revision. Put it under the inner join with AGILE.REV, and things should work just fine.

You have an error in your database. Basically, something (probably your account) tries to reference something else using ID 93583, and it isn’t in the database. It could be a role, for example, that was recently deleted (and I mean HARD-deleted).
 Run Averify and see if it points out anything linked to 93583. Also enable SQL Debug logging in the application server, try to log in (and get the error) and then disable the logging and look at the sql.log file that should have been created. Do a search for 93583 and see what it is trying to do with that ID.

The PAGE_TWO table holds most of the Page Two tab attributes (date, list multi-list, numeric, money, text, large-text), and the PAGE_THREE table holds most of the Page Three tab attributes (date, list multi-list, numeric, money, text). ID is the database id of the object to which the record belongs, and CLASS lets you know what type of object it is. All multi-text attributes are stored in AGILE_FLEX, where ID is the object ID, CLASS tells you the type of object and  ATTID is the attribute ID. Note that all flex attributes are also held in the AGILE_FLEX table. All list/multi-list attributes hold ID values that link to LISTENTRY.

The error you are seeing in the file manager log is NOT related to the issue when trying to attach a file. Note that both properties files *were* loaded successfully, just not from the original location that was attempted.
 What error was given when you tried to attach the file???  And how do you know that the file you found in the vault is the one you tried to attach??

I assume that Averify is no longer reporting any errors (other than extra tables)?? Then something else is going on, and without being able to dig around in the database, I can’t really diagnose what it is.
 I would open an SR with Oracle. They will want your latest Averify log file, and eventually a copy of the database. It may take a couple of days for them to actually look at your database, but they should be able to figure out what happening and what is causing the problems.

Ah, yes. I hadn’t seen the file you mentioned, and an image seems to be the only way to go, except for when you create a question.
 And yes, you have issues with ACTIVITY_BASELINE. The errors with REV and MANU_PARTS are easily fixable. But that error for REFDESIG is worrying.
 AGIL-00105012 is telling you that a record in ACTIVITY_BASELINE is pointing to an ACTIVITY record (using ACT_ID) that does not exist.
 AGIL-00105037 is telling you pretty much the same thing, except that it is referring to what ROOT_ID is pointing at.
 AGIL-00105038 is telling you pretty much the same thing, except that it is referring to what PARENT_ID is pointing at.
 And yes, given how the PPM schema is set up, all 3 attributes can point to different things (all of them records in ACTIVITY). So yes, your PPM data is probably fairly well hosed. No idea how many records are affected for the above 3 errors, but the messages for 105037/105038 tell you to delete from activity_baseline where the root/parent id is a specific value (the one that the script cannot find).
 There is a very handy script named “adt_generic.sql” that I think is available from the Support website, and it will fix all 3 of the above errors in your database. Like Averify, adt_generic is your friend (because it comes from Oracle/Agile). And it will handle most of the other issues as well (like the one concerning REFDESIG).
 Steps will be as follows :
1) Copy your Prod database to a test/dev environment (which will also make a backup of Prod as well).
2) Get a copy of the adt_generic script.
3) Run adt_generic.sql against the database in the test/dev environment (note that it might create quite a few tables)
4) Run Averify again, to make sure there are fewer errors. Note that all the new tables created by the adt_generic script WILL be called out as bad tables.
5) If there are no issues concerning Activity or Activity_Baseline anymore, test to see if you can now hard-delete the soft-deleted activities.
6) If #5 is successful in test/dev, make a backup of the Prod database and perform steps 2-5 on the Prod database.

 Something else to note. It is always best to run Averify when the Agile application server is stopped. I was recently involved with Oracle Support on another entirely different issue, and their advice now is to stop Agile, start Agile without letting any users log in, then stop Agile again, and *then* run Averify. I kind of understand why that is (it involves sequences and users), but for most issues, it is a bit of overkill.

Yes, please share the “oracle_averify_report.log” file that was produced from your database.

Yes, Averify is definitely called for. I can think of 2 or 3 different things that might be going on, but the solutions are not to be attempted without knowing for certain what the issue causing this is (they could possibly cause further issues by themselves). If you open an Oracle SR, that would be the first thing they would ask for.
 Post the log file, and I’ll take a look at it and let you know if  I see anything weird.

I don’t think so. Is the next revision assigned using a PX or script, based on whatever the current released revision is??? I cannot tell if there are any released revisions based on what is show in the attached document.
 But the problem is that you have 2 pending ECOs with the exact same revision. If  the new revision is assigned by a PX or script, have it check to make darn sure that that revision isn’t already assigned to another change, as is the case here. The ECRs don’t have revision values, which would lead me to believe that there are no released revisions for this item. In any event, modify one of the pending ECOs to use a different revision, and you  will be fine.

I’m with Adrian, who do you work for (Zero??) and will there be discounts available??    ROTFL
 That said, I started working for Agile Software in 2000 and have always been working with the database, mostly using DataLoad. But I really started to learn how things worked in there when I had to extract (and then load) data for a database merge project. I’ve just been keeping up ever since then. So I’ve had lots of on-the-job training, as well as access to internal stuff and people who knew more than me. Well, up until a few years ago when I left Oracle.
 Agile actually had a clause in their software warranty that specified that if a customer used SQL to alter anything in the database, the warranty was null and void. If someone screwed things up (and some did!!!), they would have to pay Agile (and folks like me) lots of money to fix it back up  Agile never published anything on the database schema (and neither has Oracle), mostly so that folks wouldn’t be unduly tempted to work around the application itself and do things directly in the database (damned engineers!!!). So for someone to try and figure things out isn’t easy, and it usually takes a lot of trial and error.
 If you know anything about relational databases, this schema is the closest to fifth normal form I have ever seen. It is about as compact (data-wise) as you can get. And yet it works very well, even for huge databases (can you say multi-terrabyte-sized dump files?). The folks who put the original schema together (whom I met a long time ago, but who have long-since retired) really knew their stuff. And the follow-on folks haven’t screwed it up (well, a time or 2, but those got fixed back up right). Then there is the PG&C stuff, and the PPM stuff……..   Don’t go there. Complicated, believe me.