XER Slim and Version

Two fixes for a Primavera P6 export, in one drop: shrink a file that has grown to hundreds of megabytes, and change the P6 version on its header so an older P6 accepts it. Everything that carries the schedule stays byte for byte.

Resize the file

The POBS table goes: orphan data P6 drags along on every import and never reads, often half the file. UDF values, notebooks, past-period actuals and resource loading are optional extras.

Change the P6 version

The header says which P6 release wrote the file, and an older P6 refuses a newer number. Pick the version you need, download, import. Nothing else in the file moves.

Drop your .xer here, or

Resize it, change its P6 version, or both. Done in about a second, even at 500 MB.

The file stays on your machine, nothing is uploaded. Files of 500 MB and more are fine: the tool reads the bytes in slices and never decodes the text.

Original

Lean

Removed

Change the P6 version the header field an older P6 checks before it imports

P6 version in the header

P6 refuses a file exported by a newer release than its own, and the first line is the only thing it checks. Set a lower number and an older P6 imports the file; the schedule underneath is unchanged. Keep as exported unless the import fails on version.

What goes, what stays tick a group to drop it, the numbers above follow

Every table in the file rows and bytes read from the file itself

Table	What it holds	Rows	Size	Share	Fate

What POBS is. POBS stands for Performing Organizational Breakdown Structure, an internal table P6 Professional started writing into XER exports around release 15.2. No project references it, no view shows it, and P6 has no screen to edit it. The bug is in the round trip: every import copies the file's POBS rows into the database, and every export writes the whole database table back out, so the table grows on each hop between companies and never shrinks. A schedule of twenty thousand activities ends up in a 400 MB file that takes hours to import, when the schedule itself is 40 MB. Oracle closed the growth in 16.1, but any database that was ever polluted still exports the rows, and every contractor file that passes through it carries them on. Deleting the table from the file is the accepted remedy: P6 skips tables it does not find, and nothing in the schedule points at a POBS row.

You can do both by hand. An XER is a tab-separated text file. Open it in Notepad, and the version P6 checks is the second value on the first line (ERMHDR 15.2 ...): type another number, save, and an older P6 accepts the file. POBS is a block that starts at the line %T POBS and runs to the next line starting with %T: select it, delete it, save. The catch is the size. A 300 MB export takes Notepad minutes to open, the POBS block is hundreds of thousands of lines to select, and Notepad++ or Excel can change the encoding or the line endings on save, which is when a file that imported fine starts failing on "invalid format". This page does the same two edits in about a second, on the bytes, without opening the text at all.

What the tool never touches. Projects, WBS, activities, relationships, calendars, activity codes and their assignments, resources, cost accounts, currencies, UDF definitions and the file header stay exactly as exported: the lean file is built from byte ranges of the original, so encoding, line endings and column order are untouched. The optional groups are for when you only need the dates and logic (a review with XER Health, a diff with XER Compare, a Gantt with XER Gantt) and not the resource loading or the notebooks. Leave them off when the file goes back into a P6 database that owns those values.