Blog

You are here: Home / Blog

Dec

Viewing Data in a Shared Database

Categories: Databases, P6 EPPM, P6 Professional, P6 Web

Tags: Multiple Users, Primavera P6, Shared Database

Comments Off

by Bill Pepoon

Primavera P6 users who share a database with other users will not see the most current changes being made by the other users right away. The other users must commit their changes, and then the user will be able to refresh his or her screen to see these changes. We will discuss how changes to a project are committed to the database first.

Most users commit their changes to the database without realizing it. For that matter, many users are not even aware of any specific procedures for committing changes. Yet it happens on a pretty regular basis as long as the other users take one of the following actions:

Closing the application
Choose File, Commit Data (F10)
Choose File, Refresh (F5)
Summarize Projects
Apply Actuals
Schedule
Import/Export
Delete a resource
Delete a project
Change a user password
Open a project
Close a project
Save a project baseline
Save a layout in Tracking View
Add a resource and complete the New Resource Wizard
Create a new Report using the Report Wizard
Import or Export a report
Select a baseline project to use and click OK
Edit a calendar from Enterprise, Calendars
Delete a Resource Shift from Enterprise, Resource Shifts
Modify a Resource Shift and click Close
Leveling resources

Whew! And that is not even the complete list! So if the other users are moving around the program quite a lot they will probably commit their changes to the database by “accident”. Which is fine, but if someone is adding a long list of activities and doing nothing else, other users who open the same project will not see these changes. But as seen below, switching from one of these views to another will also commit changes:

Projects View
Reports View
Resources View
Tracking View
WBS View
Work Products and Documents View
Activities View

Once the changes have been committed to the database then other users simply need to refresh this data on their screen. Thankfully, this list is pretty short:

Choose File, Refresh
Save a copy of the current project as the baseline
Choose Tools, Check Project Integrity
Selecting Apply on various windows within P6

The user making changes would not lose them because he or she failed to commit changes for the simple reason that closing Primavera P6 automatically commits changes. For that matter, I have never seen a situation where data was lost even when Primavera P6 crashes. So the only concern is whether other users are seeing the latest revisions.

Dec

Using Activity Steps

Categories: Activity Steps, P6 EPPM, P6 Professional, Primavera layouts

Tags: Activity Step Templates, Activity Steps, Layouts, P6 Professional

Comments Off

by Bill Pepoon

Activity Steps offer several advantages. One, you can break down a complex activity into a series of, well, steps that better describe the scope of work. The activity name does not need to go into a great deal of detail because the steps offer additional explanation. Two, it becomes much easier to update a complex activity with steps because rather than trying to come up with a percent complete for the overall task, each step is updated individually, thereby generating an overall percent complete. Have you ever decided that an activity was 37.25% complete? Me neither, but Activity Steps can do that.

Third, Activity Steps do not requite logic so it is a great way to track work that cannot easily be sequenced. Let us say there are several air handling units in the building and you have been told that only one will be installed at a time due to the available manpower. But no one knows the order in which the AHUs will be installed. No problem. We can list the AHUs as Activity Steps; the work cannot proceed out-of-sequence since there is no predefined sequence.

In order to use steps we must first tell P6 that we are planning to use steps. This is done in the Projects detail window, under the Calculations tab:

This box is normally unchecked by default when a new project is added to the database so it is very important to take care of this right away. Next, activities that will be using steps must have “Physical” as the % Complete Type:

Note that other activities in the project can still use “Duration” or “Units” as the % Complete Type. Now we are ready to add Activity Steps. In the next screenshot I have added a series of steps for the activity Build Retaining Wall:

Each step is assigned a Step Weight, which then determines the Step Weight Percent. The total of all the steps will automatically equal 100%. The columns shown above do not show up in a typical layout so it will be necessary to add them by right-clicking in the Steps tab. You will find them in the General category of columns.

When updating an activity with Steps you must first record an Actual Start date. The Step % Complete column is used for activities that have started but are not complete. Otherwise, checking the Completed box closes out the Step.

If you expect to use the same Steps on other activities (or other projects) then it is a good idea to create Activity Step Templates:

These templates can then be inserted into the Steps tab for activities.

Perhaps the only disadvantage of using Activity Steps is that the Step Names cannot be displayed in the Activity Table – only the number of Steps – so a printout does not convey as much information as what is visible in the Steps tab. Still, I see the Steps as something used by the scheduler to status the activity more accurately.

So the only question is, how will you use Activity Steps?

Oct

Dissolving vs Deleting P6 Activities

Categories: P6 EPPM, P6 Professional, P6 Tricks, P6 Web

Tags: delete activities, dissolve activities, open ends, Primavera logic

Comments Off

by Bill Pepoon

We all make mistakes, or perhaps the scope of work has changed, which leads to activities being deleted in the schedule. And most users will simply delete the unnecessary activities. This, however, often leads to open ends in the logic. After all, you might be deleting the only successor to another activity in the schedule, or deleting the only predecessor to another activity. To avoid this problem, I dissolve activities instead.

All of the current versions of Primavera scheduling software have the ability to dissolve activities: Primavera Contractor, Primavera P6 Professional, and Primavera P6 EPPM. But dissolving activities is nothing new, as Primavera P3 incorporated this feature many years ago. Regardless, many P3 users ignored the feature and continue to do so in the current programs.

So what exactly does “dissolve” do? Well, when you dissolve an activity its predecessors are linked to the successors of the dissolved activity. Say for example that Activity A precedes Activity B, which in turn precedes Activity C. Dissolving Activity B would result in Activity A becoming a predecessor to Activity C. In theory this should be an acceptable change to the logic, since Activity A was already an indirect predecessor to Activity C.

Here is an example of how the dissolving process works. In the screenshot below I have three activities, each with a duration of 5 days, linked together using Finish to Start relationships. So the total amount of time required for these three tasks in 15 days:

In the next screenshot, I have highlighted Activity B and then right-clicked to select dissolve from the menu:

Now that Activity B has been dissolved, Activity A is a predecessor to Activity C and the total amount of time has been reduced to 10 days:

Easy as pie, unless I’m the one baking it. While it is always a good idea to check the Schedule Log for possible open ends elsewhere in the schedule, there should be no open ends as a result of dissolving activities.

Any questions? Feel free to contact me.

Sep

Delete POBS Data in an Oracle XE Database

Categories: Oracle XE Database, P6 Professional, POBS Table

Tags: Oracle XE Database, POBS Table, Primavera P6 Professional

Comments Off

by Bill Pepoon

Several people responded kindly to my post regarding how to Put Your Primavera XER File on a Diet. Mostly I focused on how to shrink the size on an XER file after it has been exported from a database, Microsoft (SQL) or Oracle (XE). I also explained – briefly – how to delete POBS data in an Oracle database so that it is not exported in the first place. Both solutions are important. For example, if someone sends you a bloated XER file you want to delete the worthless POBS data before you import it into your database. Otherwise, your database becomes bloated. Also, it significantly reduces the amount of time required to import XER files. We have heard from users saying it takes hours to import larger schedules. That is ridiculous! It should never take more than a few minutes to import one schedule.

However, I realize that some users need more specific instructions regarding how to delete POBS data from an Oracle XE database. So today I am going to describe each step in detail:

Step One – Locate the Oracle XE Database Home Page

Unless you are using Windows 8 or later, simply click on Start > All Programs. Oracle XE is a program, after all. Starting with Windows 8, all programs are treated like apps so I have to look in my apps group. Ugh! But here is what you are looking for in Windows 8:

Select Got to Database Home Page. Note that all of the Oracle/Primavera apps are grouped together. Double-click to launch the home page. This might take fifteen seconds or so.

Step 2 – Log Into the Database Home Page

Once the Database Home Page loads you will be presented with the following login screen:

You must use ADMPRM$PM as the username. Elsewhere you may have read that SYS is the username, but this username does not give you permission to execute commands. Your password is the same password you used when setting up the database. Hopefully you wrote it down because recovering it is not fun.

Step 3 – Select SQL Commands

After logging in you will be presented with a screen similar to the one below. You need to select SQL Commands > Enter Command:

Step 4 – Enter the Count Command

The Oracle Knowledge Base suggests that the following command be entered:

select * from pobs;

This does work. However, it will display all of the POBS data without giving you too much appreciation for how many lines are actually in the database. Use the command below instead:

select count(*) from pobs;

And yes, you do type the semicolon!

Then click on Run.

This command (and the results) is shown in the next screenshot:

Note that in the bottom part of the pane the count is zero. This is because I had already run the command a few days ago. At that time, the count was 86,987 (!) Not surprisingly, my XER export files were getting pretty chunky. A typical XER file for me is less than 1 MB but until I ran this command I had no exports smaller than 14 MB.

Step 5 – Enter the Delete Command

The final step (yeah!) is to delete the unwanted POBS data. Modify the previous command to read:

delete from pobs;

Again, make sure you include the semicolon. Also, note that you do not necessarily have to run the other command mentioned in my previous posting:

commit;

Oracle XE has an option to autocommit all commands. You will see this option in the upper left-hand corner of the screen. You won’t hurt anything by running the command but it is superfluous (just like my brother-in-law, but he thinks I’m giving him a compliment…)

A couple of other things:

The Oracle Knowledge Base also suggests running a couple of “trigger” commands after deleting the POBS data. This is not necessary in an Oracle XE database.
If you continue to import XER files that contain POBS data you will need to delete this data on a regular basis. Again, my original posting explains one way to clean up XER files prior to importing them.

In another post I’ll discuss three methods of backing up an Oracle XE database.

Aug

Weird Negative Float

Categories: Level of Effort, Primavera P6, Total Float

Comments Off

by Bill Pepoon

There are several settings in Primavera P6 that can have unintended consequences, but perhaps none is worse than what I am about to describe. Primavera P6 users know that negative float can be induced by putting a constraint into a schedule. A Finish On or Before constraint, for example, will generate negative float if the activity is now scheduled to finish beyond the chosen constraint date.

But can a schedule with no constraints generate negative float? A reasonable person would say “no”. After all, if there are no constraints in the schedule the project can extend to any date. So negative float is simply not possible. Who could possibly argue otherwise?

Well, I can! Because I have seen it in action. Let me set the scene. I was at the Kennedy Space Center teaching a Primavera P6 class to a NASA contractor last year when one of the class participants presented an unusual problem. His schedule had negative float but no constraints.

I was quite sure he had forgotten about the Must Finish By constraint. It does not show up in the Schedule Log and no asterisk will appear in the date columns. Nope. My client truly had no constraints in his schedule. Yet some activities had negative Total Float.

The contractor commented that all of the negative Total Float seemed to be on Level of Effort activities and nowhere else. Yet the predecessors and successors to the Level of Efforts had positive float. Huh?

This is one of those situations when I wish I still had some hair to pull. I use Level of Efforts in pretty much every schedule and have never had any problems – regardless of whether any constraints were being used. Some setting or calculation in Primavera P6 was clearly off. After some research in the Oracle Knowledge Base (Document ID 988077.1) the culprit was located.

In Primavera P6, Total Float can be calculated by one of three methods:

Start Float = Late Start – Early Start
Finish Float = Late Finish – Early Finish
Smallest of Start Float and Finish Float

These options are found under the Schedule Options, as seen below:

Right out of the box, Primavera P6 always calculates float using the middle option, Finish Float = Late Finish – Early Finish. And most users would probably not consider changing the calculation method if for no other reason than not understanding why it would make a difference. The NASA contractor had likewise always used this method of calculating float until someone decided to play with the settings. By shear luck, this happened between our training sessions at Cape Kennedy.

There are of course a lot of settings in Primavera P6 that could change the way a schedule behaves. In this situation, no one remembered changing the Schedule Options. The schedule had just been updated, but not for the first time and previously there was never a problem with the float. Seemingly overnight, the float had just gotten weird.

The NASA contractor had switched the calculation to float = Late Start – Early Start. Primavera P6 calculates float values for both the beginning and end of each activity because the values can be different whenever the relationship type is not Finish-to-Start. You probably did not know this (or even care!) but it can make a difference. But any float calculation method other than the one using late dates results in erroneous float being displayed on Level of Efforts.

In the next screenshot I am displaying a Level of Effort activity with negative float.

As you can see in the Activity Details, the predecessor and successor tasks do not have negative float. But why negative float? I have an answer but not an explanation. The negative float is being calculated as the difference between the actual start date of the Level of Effort and the Data Date.

Think about it. Primavera P6 considers the Level of Effort as being behind schedule because it has an actual start date that is before the Data Date. Where else should the actual start be?

In the schedule above the Level of Effort started the day before the Data Date so it is theoretically a day behind schedule. Ridiculous, but that is how Primavera P6 is calculating the float for Level of Effort activities.

Choosing the third method of calculation, Smallest of Start Float and Finish Float is still a bad idea because a negative number would still appear on the Level of Effort. According to Oracle, Start Float and Finish Float is usually the same, but can be different on both Level of Effort and WBS Summary activities.

Why? Who knows, but it keeps me on my toes!

Jul

Put Your Primavera XER File on a Diet

Categories: Oracle XE Database, P6 Professional, POBS Table, Primavera P6, Primavera XER

Tags: Oracle XE Database, POBS Table, Primavera P6, Primavera XER, XER Size

Comments Off

by Bill Pepoon

You have probably noticed that after using Primavera P6 for a while your XER files seem to be getting bigger. Actually, a lot bigger. Files that used to be under 1 MB are now more than 10 MB. This slows down the importing of XER files considerably and makes it harder to email files without using a large-file service like Hightail or Dropbox.

According to Oracle, this problem affects Versions 7.0 and later.

The XER file format is the most popular way to exchange project data between databases. As a consultant, I always have to send my files to the client. There is another Primavera format – XML – but these files tend to be rather large compared to Primavera XER. The beauty of the XER format is that it is text-based, which normally results in a very small file.

Nevertheless, XER files have a bad habit of getting rather chubby, if not downright HUGE. This would be understandable if it served some purpose. Unfortunately, the increased size is a complete waste of space. And in some cases it takes so long to import the XER file that P6 effectively locks up. Not good.

Specifically, the problem is the POBS Table. Join the club if you have never heard of this data field. Here is the official explanation from Oracle as to the purpose:

Functions related to table POBS have not been implemented yet so the table has not been put to use. The table may be removed in a future release.

You do have to wonder, if Oracle has not found a purpose for the POBS Table yet, why has its use persisted for so long? This is not the first time a feature showed up without a purpose. For several years Primavera P6 displayed a colored bar next to the Activity Code Values. The default color was blue. Regardless, changing the color did nothing because the feature was intended for Visualizer, which had not been incorporated yet:

Since the POBS Table is not used at all, we might as well delete it. Granted, if your XER files are rather small it is not a necessary step. Until recently all of my XER files were reasonably sized considering the size of the projects. But starting several months ago my XER files started gorging themselves. A POBS Table with a few dozen lines suddenly had thousands of lines. Deleting the POBS Table became a necessity for me.

Assuming you are using an Oracle database it is rather easy to delete the POBS Table in the database so that export files do not include this table by running the following statement inside the database after backing it up:

delete from pobs;
commit;

**UPDATE** Please see my post regarding how to Delete POBS Data in an Oracle XE Database for more detailed instructions on how to execute the above commands.

Files being imported into the database, however, most likely will have the POBS Table. So it may become necessary to modify the XER files prior to importing them. Here are the steps:

Make a copy of the XER file (just in case!)
Open the XER file in a text editor like Notepad
Find (Ctrl+F) the line that starts with %T POBS
Select the following lines that start with:
1. %T POBS
2. %F (including all line content)
3. %R (including all line content)
Stop at the next %T
Delete the above lines
Save the XER file
Import the XER file

Below is a screenshot showing each type of line that must be deleted:

Note that lines that start with %R may number in the hundreds or even thousands. The above image does not reflect the thousands of %R lines that existed in this particular XER file.

The next %T will be very close to the end of the file. The rest of the lines pertain to project data that should not be deleted, which is why we stop at the next %T. The biggest headache is getting all of the %R lines highlighted.

Still, deleting the POBS Table can yield startling results. Starting with a XER file that was 14.4 MB (14,377 KB) in size, I employed the technique described above to delete the POBS Table. The new XER file was just 105 KB (!)

It is always a good idea to make a backup copy of the XER file just in case you delete the wrong lines. But otherwise this is a quick and easy way to drastically reduce the size of XER files.

Update: starting in 2016, Oracle introduced SQLite as the default database for standalone users. This new database does not use the POBS table and therefore the problem I am describing no longer occurs.

Any comments or questions? Please email me.