100 Global Calendars -

Before looking at the detail of your query, I should say that it relates more to contract management and politics, than project controls.  If a ‘job’ (I hesitate to use the word ‘project’ which is a reserved word for P6 users) has a single list of agreed deliverables, then it should be managed in a single P6 database, so your issue does not arise. That is seldom possible due to 20^th century thinking about, amongst other things, the competition between owners and contractors, and the failure of contract management to pay any effective attention to project controls.

‘I work on many projects, how do I ensure my 100 calendars and tons of resources etc do not infect the machines of people I give projects back to? ‘

This is not your problem. This has been understood by P6 users for almost 20 years. You are either sharing resources and calendars, or you are not. The export from P6 is only ‘all data’, the import can be partially controlled. The ‘importer’ should understand what data they require by reference to the contract (no laughing at the back), the rush to create separate P6 plans without agreeing everything in advance is a category error, often resolved in court. I am available, for the usual exorbitant expert witness rates.

 ‘Shouldn't everyone always use Project Calendars if you ever share?’

NO! well, let me expand little. ‘Job’ calendars should be used, these need to be ‘Global’ in P6 terms, because you are sharing data across databases.

 'Shouldn't people always use "new Calendar" on import because changes to an existing calendar would change old schedules, correct? '

NO! same answer as above. Yes, existing schedules might be changed, by a planner ‘accidentally’ changing an agreed calendar in one database, and it being imported into another. P6 is rubbish at management and housekeeping of its own data. Human intervention is required, and of course MUST BE BUDGETED AND PAID FOR.

‘How do you avoid proliferation then?’

Spend money on housekeeping. My ‘UK all-comers record’ is single P6 database with 127 identical 7x12 calendars. Ker-ching.

 Are there differences in P6 versions regarding the handling of Calendars?

Not significantly, there have been improvements in importing calendars, but no significant ones since, I think, version 8.

John its not as simple as just "always use Project Calendars". Even if you try to do this as best possible, any reference in the XER back to a global calendar will create that calendar in the destination Database. For example - you might have a realtionship to an external project that isn't part of the XER you generate, hwoever, the xer contains:

- The external activity

- The external activity's project and WBS ID, that may include a global calendar as the default.

- The external activity's calendar, that may well be a global calendar.

My recommendation is to always PREFIX the calendar you create to easily identify what EPS node they are used for. Now how tidy you have to keep the data ultiamtely depends on how tidy the receipient needs it to be. Some don't care and import anything and everything. Others have very strict import requirements and may even use 3rd party solutions to modify the XER before importing into their database.

First you need to know if the project that you are importing uses glaobl or project calendars then you can choose the best option during the importing process.  I perfer project specific calendars.