In order to avoid database contamination, in your case with the RISKTYPE data, I will recomend to clean the file with ScheduleCleaner.
[[wysiwyg_imageupload:7182:]]
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
Member for
16 years 3 months
Member for16 years4 months
Submitted by Zoltan Palffy on Mon, 2019-07-01 14:11
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
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
Member for
16 years 3 months
Member for16 years4 months
Submitted by Zoltan Palffy on Fri, 2019-06-28 16:43
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 ?
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?
Member for
16 years 3 months
Member for16 years4 months
Submitted by Zoltan Palffy on Fri, 2019-06-28 14:13
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.
Member for
16 years 3 monthsthis will clean individual
this will clean individual xef files but not the database go into the software and delete them manually
this cleans POBS and RISKS Types
http://scheduleanalyzer.com/sae_p_POBS.htm
Member for
8 years 7 monthsHi Rik,In order to avoid
Hi Rik,
In order to avoid database contamination, in your case with the RISKTYPE data, I will recomend to clean the file with ScheduleCleaner.
[[wysiwyg_imageupload:7182:]]
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
Member for
16 years 3 monthsif you are not using the risk
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
Member for
6 years 4 monthsHi ZoltanThanks for the
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
Member for
16 years 3 monthsRik why not try the utility I
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 ?
Member for
6 years 4 monthsHi ZoltanThanks for the
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?
Member for
16 years 3 monthsyou will have to clean them
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
http://scheduleanalyzer.com/sae_p_POBS.htm