Issues in Soft-Deleting Activity
We are getting “Activity XXXXX does not exist” while trying to hard-delete the activities from re-cycle bin.
We verified from back-end the activity exists with “Delete_Flag=1”.
We are facing the same issue while we try to Inactive the User who is assigned as the task-owner.
Does this need A-verify or is there any approach/fix/suggestions we can try out.
Regards,
Arif
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.
Meanwhile you are waiting a solution by OTN , if you want to hard delete the element you can try to use SDK.
you should be able to get the Item (or whatever object) calling session.getobject method and then, on the IDataObject, you can call one delete(). if you run the code with a user with full privileges, you should be able to hard delete it.
IChangeobj = session.getObject(IChange.OBJECT_TYPE, “MyDeletedChange”);
obj.delete();
Hi Antonio,
Thanks for your comment. Yeah exactly the same approach i have using SDK however my customers want to ensure that their won’t be any issue in setting the user as inactive who is task owner for these tasks.
At the moment while trying to inactive the user we are getting the issue like Activity already deleted.
Regards,
Arif
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.
Ran A-Verify in lower environment where the issue was reproducible. Cleared all the errors the issue still persist.
Regards,
Arif
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.
Just sharing Issue Fix for reference of other folks
=====================================
Root-Cause : It happens when root activity is deleted while it’s children are still in db.
Fix :
1. Backup database.
2. Then run below sql to make sure activity 862302 is gone(The sql should return 0 results):
select * from activity where id=862302
(The Activity ID which was coming on screenshot)
.
3. Create a new project using web client, e.g.a project named ‘Testxxxx”. (Can be any name).
4. Find this Testxxxx in database and get its id, e.g:1856367 .
5. Change the id of this fakeproject to 862302 and owner to User for which the issue was coming:
update activity set owner=[id of impacted user], id=862302 where id= [id of fakeproject];
commit;
.
6. Restart agile server and try to inactivate the user, and then delete his projects.