(1) Explain your problem, don't simply post "This isn't working". What were you doing when you faced the problem? What have you tried to resolve - did you look for a solution using "Search" ? Has it happened just once or several times?
(2) It's also good to get feedback when a solution is found, return to the original post to explain how it was resolved so that more people can also use the results.
Hi all
We have recently been experiencing a large number of completely spurious RISKTYPE categories being passed around between ourselves and the organisations that we regularly exchange programmes with.
The RISKTYPE data seems totally spurious, with random characters / nonsensical text, and it seems system generated - in the sense that its not names that people have typed.
As with POBS contamination, these RISKTYPES are being exported automatically into XER files which are then being imported into other databases and passed on to other organisations. This has now, to my knowledge, infected up to 10 other organisations within our work area.
I know how to remove the data, both from the XER file (either text editor or excel file parser) and from the database (initially from admin settings or if that fails via a delete query on the database), but the problem is that its affecting other organisations and that are not dealing with the issues. It feels like a virus contamination almost.....
Not only is the data spurious, but it contains unreadable characters which cause the file parser & the Pertmaster import utility to fail. This causes a number of problems. Additionally, the data has some structure to it, but its erronious, which causes the EPPM admin module to fail to display much of the coding - thus forcing the need for the delete query.
The volume of spurious codes is regularly swelling - as it seems that each time an infected file is imported it adds to the codes. The amount of data is massive. One dtatbase was contaminated with over 80,000 lines of RISKTYPES. The following lines are a sample of the code names created :
??H?H?H?õ ?‘?H?Ã
A?A?‘?÷levA?A?
AutomaD?Ha?H?HD?fA??D?Ha?H?HD?Ha?H?ÃÃAs you can see - no human would create this - so im wondering if this is some form of error in P6.......
Has anyone experienced this problem too? And can anyone shed any light on why this is happening?
Im managing the problems in our DB, but we keep having to clean every imported XER, and missing one leads to re-contamination......
My databases are P6 EPPM v16.1, and the software is fully patched and managed by Loadspring - so i dont think there is a problem at my end... Our colleagues use a range of P6 versions, but thats out of my control.
Any ideas please?
Cheers in advance.
Printer-friendly version
Send to friend
this will clean individual xef files but not the database go into the software and delete them manually
this cleans POBS and RISKS Types
Hi Rik,
In order to avoid database contamination, in your case with the RISKTYPE data, I will recomend to clean the file with ScheduleCleaner.
The software can clean 77 categories of of project data including Risk Categories. Moreover, you can add Prefix and Suffix as well as Mask project data and convert Global to Project Calendars, EPS to Global Activity Codes and Global/EPS to Project Activity Codes.
Hope that helps,
Joel
if you are not using the risk type the other option is that during the importing of the xer file when you get to the Update Project Options select Modify and then under Data Type: Project RISK in the action column select Do Not Import
Hi Zoltan
Thanks for the reply
Unfortunately, as i have inherited a nmber of legacy databases (and setup new ones of my own) i have a set of legacy user profiles & pemissions which i have to maintain. one of these is the ability for about half of the users to import XER's.
This means that im reliant on a pool of users makingh sure that they remember to check for RISKTYPES in each and every XER.
It s not that the RISKTYPES are difficult to spot or remove from the XER - as you sas, its very simple to remove even with MS Notepad, or a 3rd party app. But once they are in the DB it means that they are hard to remove becase the data corruption makes it hard to remove some from the DB. SOme can be removed from the EPPM management interface, but some just cant.
I dont think that its a multi language problem, as none of the other organisations are anyting but english speaking 1st language (as far as planning is concernrd anyway).
Its possible that there is some kind of issue in the XER creation, but when asked, they just use a very standard P6 install and nothing odd or fancy, so it must be either corrupted data that they have been exposed to or a fault in the P6 code.
If this is not something that other users have experienced regularly then it must fairly be specific to us.
It all seems quite odd
Rik
why not try the utility I sent you it might pick up the ones that yours have missed.
I have several databases one in particular is a proposal database. I never bring ANY xers inot this database and the Risk Types are CLEAN. So I ma 100% convinenced that the funkey character came in through an xer import. They may have been created during the creation of the xer file itself.
You can also manually delete the risk types in the xer if you know none exists
Edit the XER file and remove the Risk categories.
Search for %T RISKTYPE
Find the next %T
Delete the lines beginning with %T RISKTYPE through the line "prior to" the next %T
Save the file.
Import the XER.
I wil have Ron look into this.
It is possible that the funkey characters me be generated from other languages being used ?
Hi Zoltan
Thanks for the link.
However - As you can see from my original post - I already understand how to clean the RISKTYPES - from both the XER's and the database. We already use a file parsing tool like the one your link describes, but because of the corrupted characters, it cant always read the file. Leaving us with a manual clenup operation.
As some of the planners have XER import rights , there is a continued risk of importing this type of data. so im trying to understand WHY this is happening. RISKTYPES are a vaild form of data (albeit not so much in EPPM as the desktop P6 does not have the functionality to use it in v16.1). It seems like there is a problem in P6 creating this data.
This isnt unused functionality like we had some time ago with the POBS problems
Our planners are instructed to manually check and clean every XER file that comes in, but there is always one case where there is a risk that it gets forgotten.
Also, as there are spurious entries in the database table for parent_risktype, this means that alot of the created categories "hide" thenselves in the database, meaning that you CANNOT delete them from the admin interface in P6. This then requires support assistance from the Loadspring admins to take the DB down and run a delete query on the RISKTYPE table. Creating support charges.
Im trying to understand how and why this is happening, and whether its something that alot of people are experiencing, or whether its just us and our partner organisations (and im not referring to small companies - we deal with Network Rail and TFL - whi are getting this too).
Any further thoughts from anyone?
you will have to clean them manually from the databse but once you clean them then you can clean ALL xer files prior to importing based on the link I have provided below
If you look under Admin then Admin Categories and look under the Risk Types tab you may see a lot of junk risk types there. To clean these you will have to manually delete them. However in the future you can clean the xer file of the POBS tables AND rubbish Risk Types prior to importing the xer file into the database. A big thanks to Ron Winter for looking into this and modifying his POBS cleaner program to include the Risk Type cleaner.
Here is the link to his revised cleaner
Email: PPadmin@planningplanet.com
Replies