Projects, one page: {total, offset, returned, next_offset, rows}. Row: Project ID, name, data date, planned start, scheduled finish, status (of the project WBS node), baseline_of, and the EPS node holding it: eps_id, eps_name, eps_path (EPS names from the top, joined with ' > '); all three None for a project outside every EPS node. EPS nodes are never listed; baselines only with include_baselines=True (baseline_of is set); exclude_templates=True leaves out the P6 template projects (status WS_Template, or no EPS node). eps= an EPS ID: the projects of that EPS node and of every EPS below it. order: 'project' (Project ID) or 'eps' (EPS tree order as p6_list_eps order='tree', then Project ID; projects outside every EPS node last).

WBS tree in P6 order (each node before its children), one page: {total, offset, returned, next_offset, rows, root}. Row: wbs_id, parent_wbs_id, depth (project node 0), wbs_code (as P6 shows it, e.g. 'PRJ.5.1'), wbs_short_name, wbs_name, children (direct), and with rollups=True the rollup of its whole subtree: activities, open (not completed, LOE and WBS summary left out), not_started, in_progress, completed, min_tf_d and negative_float (open activities, days of each calendar), start, finish (actual, else early), budget_units, actual_units (labor plus nonlabor), units_pct (actual / at completion, as P6 Units % Complete) and bl_planned_pct: baseline planned units at the data date / baseline budget units of the subtree, x 100 (the baseline's labor and nonlabor assignments placed by the Activity ID of the current activities, linear between their planned dates as p6_progress_curve and the dashboard; None without a baseline, a data date or baseline units). baseline= a Project ID (default: the project baseline); the result says which one (baseline). parent= starts at that WBS code, full or relative to the project node ('5.1'); max_depth counts levels below the start node. root repeats the start node (unplaced = activities outside the tree, when it is the project node).

Search activities, one page: {total, offset, returned, next_offset, rows}, ordered by start (actual, else early) then Activity ID. status: TK_NotStart, TK_Active or TK_Complete. Dates as YYYY-MM-DD (finish_before includes that day). wbs_name_contains matches the name of the activity's own WBS node only, not its parents: for a whole branch use p6_list_wbs, or an activity code filter. Durations and float in days of each activity's calendar. code_type (activity code type name, e.g. 'Discipline'; the project's own type wins over an EPS or global one) keeps activities with a code of that type; code_value narrows it to a code by path ('CON.MEC'), short name ('MEC': every match) or name, with its child codes unless include_child_codes=False; code_filter tells what was matched. fields= keeps task_code plus the fields named, e.g. ['task_name', 'early_start_date', 'early_end_date', 'total_float_d'], for smaller pages. UDFs (user defined columns, p6_list_udfs): udf_filter = [{udf: label, op, value}], all to hold; op eq (default), ne, lt, le, gt, ge, contains (text), empty, not_empty; a date alone covers the whole day; udf_filter (info) tells what was used. udfs = labels added to each row as udfs {label: value} (None when empty).

Full detail of one activity: the list fields (see p6_query_activities), secondary constraint, remaining, expected, suspend and resume dates, calendar (hours_per_day converts hours to days), WBS (wbs_code as in p6_list_wbs, wbs_path names), predecessors and successors (first 50 of each, with predecessor_count / successor_count; page further with p6_get_relationships), assignments (resource and role, quantities and costs as stored), activity codes, UDFs and notebooks (first 50 of each), lag_rule and schedule_state.

Relationships of an activity, one page: {total, offset, returned, next_offset, rows, lag_rule}. direction: pred, succ or both. Lag in hours (lag_h) and days (lag_d); lag_rule tells which calendar converts lag days (project schedule option, predecessor calendar by default).

Critical activities of the last P6 schedule run (F9), one page: {total, offset, returned, next_offset, rows, definition, mode_used, threshold_h, counts, schedule_state, note}. mode: project (default) follows the project setting (total float <= its hours threshold, or longest path); total_float uses that hours threshold; longest_path uses P6's driving path flag. float_threshold_days forces total float <= that many days (not with longest_path); min_float_days keeps only total float > that many days (days of each activity's calendar, not with longest_path): min_float_days=0 with float_threshold_days=10 lists the near critical activities. LOE and WBS summary activities are left out (even when P6 flags them), completed ones too unless include_completed=True. Order: total float then start, or float path order for the longest path. counts (open activities except LOE and WBS summary, any page): open, total_float, longest_path, negative_float; excluded_summary = LOE and WBS summary activities that meet the definition and the status filter but are not listed. fields= as in p6_query_activities.

DCMA 14 point assessment of the last P6 schedule run (F9). checks: logic, leads, lags, long_lags, fs_links, hard_constraints, high_float, negative_float, high_duration, invalid_dates, resources, missed_tasks, critical_path_test (this server's CPM engine: the earliest lowest-float open task delayed 100 working days must move the project finish as much; not run when the engine does not match the F9, see p6_cpm_validate), cpli, bei; each {count, denominator, pct, threshold, pass, sample (15)}; then key_dates (information only: constraint dates against the must finish date, the work after them and each other; count = issues, pct = constraints with an issue). Open = not completed; LOE and WBS summary activities are left out, also as either end of a link; relationship checks count links whose successor is open. pct must stay at most the threshold, except fs_links (at least), cpli and bei (value at least), compared before rounding; pass is None when not evaluated. Thresholds: the project's Check Schedule settings (PROJPROP schedule_check, limits in hours) when stored, else DCMA defaults (limits 44 d of each calendar; resources has none: not evaluated unless thresholds= sets it); threshold_source says which. thresholds= overrides by check name (not critical_path_test); high_float_days sets the high float limit. lags and fs_links also give ladder_pairs (SS + FF between the same activities with the same lag) and their values without them (information). Logic exempts only the project start and finish milestones (listed); dangling starts and finishes (milestones left out, see p6_dangling) are information only. missed_tasks and bei need a baseline: baseline= (Project ID), else the project baseline; baseline_dates 'current' (actual, else early finish) or 'planned' (its planned finish); a task is missed when not finished or finished on a later day. duration_basis: remaining or original. cpli: working days of the project calendar (calendar days beside it). check= returns that check's full list of items as a page {total, offset, returned, next_offset, rows} with result (the check) instead of the whole report. A full run saves a snapshot for p6_health_check_compare (snapshot.id; save_snapshot=False skips it). The earlier top keys stay: no_predecessor, no_successor, hard_constraints, high_float, negative_float {count, sample}; leads_negative_lag, positive_lags, non_fs_links (links whose successor is open). checks.logic_density (after logic): links whose successor is open / open activities, value at least 1.5 (not in summary or score, which stay the DCMA 14). negative_float.worst and high_float.worst: the open activity with the lowest / highest total float {task_code, task_name, total_float_d}. weighted_score {points, grade, earned, max, checks {name: {weight, status pass / warn / fail / not_evaluated, earned}}}: logic_density 20, logic 20, critical_path_test 15, negative_float 15, high_float 10, hard_constraints 10, high_duration 5, leads 5, lags 5, fs_links 5; pass = the weight, warn = half (a failed at most check up to 2 x its threshold, a failed at least check down to 0.9 x it; no band for a zero threshold), fail = 0, not evaluated left out; points = earned / weight of the evaluated checks x 100; grade A >= 90, B >= 80, C >= 70, D >= 55, else F. engine_version: the CPM engine of the critical path test.

Look-ahead of a project, one page: {total, offset, returned, next_offset, rows, window, weeks, data_date, counts, critical_definition, schedule_state, note}. The window starts at the data date (or from_date; a date alone starts at 00:00), lasts days= (default 14) or weeks= calendar days and is half-open [from, to). Listed: not started activities starting in it, open ones finishing in it, not started ones spanning it (start before, finish after), every in-progress activity (include_in_progress=False keeps those finishing in the window) and, with include_completed=True, completed ones whose actual dates overlap it. Open activities use their remaining dates (early when empty) of the last F9. LOE and WBS summary activities are left out. Each row has window: the categories it meets (in_progress, starting, finishing, spanning, completed), critical (open and critical under the project definition, as p6_critical_path), fcst_start (actual start, else remaining start), fcst_finish (actual finish when completed, else remaining finish) and start_week / finish_week: the week of the window holding that date (1 = the first 7 days from the window start, None outside the window; weeks lists each one's from and to). critical_only=True lists the critical ones only. counts gives the categories and critical over all pages. wbs_name_contains, code_type / code_value / include_child_codes and fields= as in p6_query_activities. Order: start, finish, Activity ID.

One-call overview of a project (values of the last F9): project (name, calendar), dates (data date, planned start, must finish by, scheduled finish, last schedule run, first start and last finish of the activities, scheduled finish minus must finish by in calendar days and in working days of the project calendar (None when it is unreadable)), activities (by status, by type, open, open milestones), relationships (successor in the project; from and to other projects), critical (counts of open activities, LOE and WBS summary left out, as p6_critical_path), percent_complete (primary = units: actual / at completion units, labor plus nonlabor, P6 Units % Complete as p6_list_wbs; p6_progress_curve gives % of the budget instead; physical: physical % weighted by budget units; duration; activities completed; units_vs_physical_mismatch: activities with units whose physical % and units % differ by more than 0.01 point), baseline (the project baseline, baselines attached, the one used: baseline= else the project baseline, its scheduled finish and data date; every key present, null without a baseline; finish variance = scheduled finish minus the baseline's scheduled finish in calendar days and in working days of the project calendar, baseline planned units % at the data date and spi_units = earned units / baseline planned units, earned value and linear spread as p6_progress_curve), counts (WBS, assignments, resources, calendars, code assignments) and schedule_state.

Total and free float distribution of the open activities (not completed, LOE and WBS summary left out) of the last F9, in days of each activity's calendar. Buckets from edges_days (default -20, -10, -5, 0, 5, 10, 20, 44; 0 is always added): below the first edge, [a, b) below zero, exactly 0, (a, b] above zero, above the last edge, so every value falls in exactly one bucket (compared in hours, never rounded). Each bucket: total_float and free_float counts, their % of the activities, and samples (the sample_size lowest floats). no_value counts activities without a float; all_ranges_covered checks that bucket counts plus no_value equal the activities. stats: min, max, mean and median in days, total floats that are not whole days, negative, zero, critical (project definition). include_milestones=False leaves milestones out; wbs_name_contains and code_type / code_value / include_child_codes filter as in p6_query_activities (code_filter in the result, as there).

Start here when a tool reports a configuration problem. Shows the server settings in force (database, tool profile, writes allowed, restart needed), the P6 schema and version detected, whether P6 is running, the backup and edit log folders. Works without a database.