Resolving 'Cannot Read Hierarchy Folder' During Save As with Reorganization in SIMATIC PCS 7

In SIMATIC PCS 7, the error 'Cannot read Hierarchy folder' occurring during a 'Save As with Reorganization (Slow)' in SIMATIC Manager indicates that the internal Plant Hierarchy database index or pointer structure (p_hier.dbf or .hie files) has suffered corruption or contains orphaned references to deleted CFC charts or OS pictures. While all client engineering sessions are closed, the slow reorganization parser fails when attempting to re-index non-contiguous folder records. To resolve this, run 'Plant Hierarchy -> Check Consistency' to identify broken references, delete orphaned database lock files (.ldb), and execute project reorganization.

Plant Hierarchy Database Indexing and Reorganization Architecture

In SIMATIC Manager, a PCS 7 Multiproject is managed via a Microsoft Access / Sybase relational database structure embedded within project folders:
* The Plant Hierarchy Index (p_hier.dbf / p_hier.mdx): Tracks technological hierarchy paths, unit associations, and relationships between CFC charts, SFC types, and WinCC pictures.
* Save As with Reorganization (Slow): A deep database compaction utility. Unlike standard 'Save As', slow reorganization reconstructs all internal tables from scratch, removing fragmented blocks, recalculating record offsets, and purging deleted objects.
* Index Traversing: During reorganization, the engine reads hierarchy records sequentially. If an offset pointer points to a non-existent disk sector or corrupted record, the process halts with Cannot read Hierarchy folder.

Root Causes of 'Cannot Read Hierarchy Folder' Abort Errors

Specific failure modes prevent database reorganization:
1. Orphaned Plant Hierarchy Records: Charts or pictures were deleted from the Windows file system directly without using SIMATIC Manager, leaving ghost records in p_hier.dbf.
2. Hidden Multi-User Locks (*.ldb): Even with all workstations seemingly closed, an orphaned Microsoft Access lock file (*.ldb) or STEP 7 session lock (*.loc) in the project directory prevents exclusive table locking.
3. Corrupted Hierarchy Level Indices: An aborted previous archive or hard shutdown during compilation corrupted the .hie hierarchy descriptor file.
4. Third-Party Antivirus File Locking: Active scanning by antivirus utilities locking database chunks while STEP 7 reorganizes binary files.

Remediation Procedure - Repairing Database Pointers and Executing Reorganization

Follow this procedure to repair the project and complete reorganization:

[Phase 1: Clear Orphaned File Locks]
   │  • Close SIMATIC Manager and all engineering tools on all network PCs
   │  • Open Windows Explorer -> Navigate to the Multiproject root directory
   │  • Search for and delete any temporary lock files:
   │      - *.ldb (Access database lock files)
   │      - *.loc (STEP 7 station locks)
   │      - *.tmp
   │
[Phase 2: Check Plant Hierarchy Consistency in SIMATIC Manager]
   │  • Open SIMATIC Manager -> Open the affected project
   │  • Select menu: Options -> Plant Hierarchy -> "Check Consistency"
   │  • Review the output log:
   │      - Note any missing charts or broken hierarchy folders
   │      - Allow the tool to repair unlinked pointers automatically
   │
[Phase 3: Execute Single Project Reorganization]
   │  • If the error persists at the Multiproject level:
   │  • Open the individual AS project component (not the Multiproject umbrella)
   │  • Select: File -> "Save As..." -> Check: [x] "With Reorganization (Slow)"
   │  • Once the sub-project reorganizes successfully, re-insert it into the Multiproject

Database Repair and Reorganization Diagnostic Matrix

Compare project maintenance states and their diagnostic indicators:

Maintenance ActionScopeDurationResolves Hierarchy Pointer ErrorsSave As (Normal)Copies files without re-indexing1-2 minutesNo (Copies existing corruption)Save As with ReorganizationRebuilds database indices from scratch10-30 minutesYes (Full structural repair)Check Consistency (PH)Validates hierarchy links and parent IDs1-3 minutesRepairs broken folder relationshipsPKZip Project ArchiveCompresses files into zip container5 minutesNo repair; archives existing state

Verification

To confirm that the project is successfully reorganized:
1. In SIMATIC Manager, execute File -> Save As... with With Reorganization (Slow) selected.
2. Verify that the reorganization progress bar completes to 100% without aborting.
3. Open the newly created project; confirm that all hierarchy folders, charts, and pictures open cleanly.
4. Run Options -> Plant Hierarchy -> Check Consistency; verify that the log reports zero errors.
5. In Plant View, confirm that inserting a new test hierarchy folder works immediately.

Limitations and Operational Precautions

Never delete .dbf or .hie database files manually using Windows Explorer unless executing an authorized disaster recovery procedure under Siemens Technical Support guidance. Manual file deletion can permanently destroy technological relationships across the multiproject. Always create a verified PKZip backup of the raw project folder before attempting database repair or reorganization.

Engineer FAQ

Why does 'Save As with Reorganization' take so much longer than a standard Save As?

Standard Save As merely copies files at the operating system level. Reorganization reads every block, parameter, and interconnection individually, sorting and repacking database records sequentially.

What should I do if the individual project also fails reorganization?

Create a fresh, empty project in SIMATIC Manager, and copy the Plant Hierarchy, S7 Program, and OS objects individually into the clean project to isolate the damaged component.

Does reorganization affect online CPU runtime?

Reorganization only affects offline engineering files. However, it can update internal block time stamps; perform an offline-to-online block comparison before downloading to avoid unexpected STOP downloads.

How often should a PCS 7 multiproject be reorganized?

It is recommended to perform a slow reorganization prior to major project version archiving, after large bulk engineering changes, or after upgrading PCS 7 versions.