replace resources

I do not use P6 but suggest adding a prefix to your project resource codes and calendar codes. 

Say you have for Masons on job 01 the code MA and for job 02 you are using the same code, then use 01MA and 02MA respectively. In this way the software will not be confused as to the details for each job. It might be that the resource limit for Masons on job 01 is 20 while on job 02 is 70.

The same goes to calendars. Say you have for Calendar 1 on job 01 the code 1 and for job 02 you are using the same code, then use 01CAL1 and 02CAL2 respectively. In this way the software will not be confused as to the calendar details for each job. It might be that the work hours and non-work days for the calendar on job 01 are different to those on job 02.

Depending on your software it might be that the rule shall also be applied to other codes such as codes for user defined fields and activity codes (different from Activity ID). 

This is an issue inherent of shared codes in P6 database structure, once a job is imported into P6 database it is no longer a stand alone job and will share some codes. The way P6 database is structured you cannot have pure stand alone jobs on a single database otherwise it would not matter how you define your codes on each job.  If locally you have a single job you might not notice the issue.

In Spider Project we can have as many separate databases we want on a single computer, every single job is a separate database file while a portfolio of jobs is another separate database file. If we import several jobs to a portfolio we will have similar issues. If we keep our jobs as stand-alone, meaning not belonging to a portfolio, then we will not have such issues. As a matter of fact I rarely use Portfolios and keep my jobs under separate files. In no way I am saying Portfolios are of little value, it all depends on your needs. For some people it makes sense to keep all jobs under separate database files, for some it makes sense to keep all jobs on a single portfolio while for others it makes sense to have a combination. I use a combination where most jobs are under separate database file, even jobs from the same clients I keep on separate database files. 

Good Luck

Gracias Rafael

I agree with you... it is very delecate decision to use enterprise or seperated resources for projects, but with the help of a colleauge I could finally manage the problem with a very easy solution:

First I changed the name of the resource to something strange that can later be distinguished easily.

Then I exported one of the projects (project A) as an XER file.

then I re-renamed the resource as it was in my PRIMAVERA data base and inported the project A again, but in import optional fields I changed the MODIFY for resources I choosed "Insert New" action.

the new project entered in data base with its new resources and the problem solved.

Gracias Rafael

I agree with you... it is very delecate decision to use enterprise or seperated resources for projects, but with the help of a colleauge I could finally manage the problem with a very easy solution:

First I changed the name of the resource to something strange that can later be distinguished easily.

Then I exported one of the projects (project A) as an XER file.

then I re-renamed the resource as it was in my PRIMAVERA data base and inported the project A again, but in import optional fields I changed the MODIFY for resources I choosed "Insert New" action.

the new project entered in data base with its new resources and the problem solved.