Drivin predecessor/successor info in SQL DB

Member for

21 years 7 months
Permalink

Member for

21 years 7 months
Permalink

  1. In-Progress Lag Report and Value. Remaining Lag should be displayed just as remaining duration is shown and editable. The CPM feature of Remaining Duration was added so that Schedulers could monitor and change this calculated duration result. Lags are to relationships what durations are to activities. Why should Remaining Lag calculations be discarded by the software instead of saved and displayed? Why should we be unable to indicate that Actual Remaining Lag is only 2 days instead of the calculated 4 days?
  2. Also Relationship Slack should be displayed; the amount of inter-activity float a relationship has in relation to other relationships with the same successor activity, measured in the same units as float for the schedule involved.
  3.  Part of the reason CPM Schedules are so hard to understand is that fact that not all of the data used is displayed.
  • You can make some of the equivalent data visible if using activities to model links & lag, but this is impractical for most of us. For 0 lag use a milestone. In these activities; Actual Duration will be the equivalent to In-progress Lag Lag, Remaining Duration will be the equivalent to Remaining Lag and Free Float equivalent to Relationship Slack.
  • I use different software and it gives me a similar table without need of additional software. Same as P6-Logic_League it misses to display some of the data, data discarded and not stored in the database. 
  • Keep in mind P6 calculations for resource leveled floats are unreliable and that P6 Longest Path calculations break under resource leveling.
  • http://www.planningplanet.com/forums/planning-scheduling-programming-di…cpm-longest-path-theory-broken-under-resour
  • https://docs.oracle.com/cd/E17462_01/Web_Access/Help/en/Projects/Tasks/pm_cpm.htm
  • Therefore I would not trust P6 calculations on resource leveled schedules.
  • Good luck,
  • Rafael

Member for

20 years 11 months
Permalink

Tom is right. Instead of old Btrieve P3 database P6 doesn't store information regarding driving predecessors, relationship float etc in database. In order to get proper access to this data you have to use Primavera API.

Regards,

Andrew

Member for

18 years 8 months
Permalink

Hi Tom,

Thanks for your reply eventhough you didn't give the answer I hoped for :-(

However, I "expected" that answer as I have not been able to find the information. We have a way of speek in Denmark when you been looking for something for a while and then other just finds it (you cannot see the forest for trees).

Member for

18 years 11 months
Permalink

I could be mistaken, but I managed to convince myself that relationship free float (and the associated "driving" flag) are not stored in the database but are instead computed and displayed by the client application.  Your reporting application would have to compute it independently - not a trivial exercise because it requires calendar math.