Problem encountered: When the undo command is performed to undo a change to a reference attachment level attribute (for example: change level symbology of a reference level, then perform an undo) and then another change is made to the levels of the same reference attachment in the same session, it will cause the level table from the reference file to be written as a level table of the active file. As a result, the file can contain multiple level tables, which behave like the active file's level table.
This issue is associated to Trouble Report 149030 and 106229
Levels in a file reside in an element referred to as a "Level Table". When reference attachments are made, a reference level table is added to the active file. This is the designed behavior. However, the sequence described in TR# 149030 causes MicroStation to incorrectly write the reference level table as a master level table, causing more than one (so called) master level table to be present in the file.
Prior to 08.05.02.35, the first level table found upon loading the file is used. This works well except in the event when there are multiple level tables associated with the active file's levels and the correct active level table is moved to the end of the file. This happens when the active file's level table data size is increased (IE: adding a level). After the "correct" active file's level table is moved to the end of the file and it is reopened, the incorrect level table is found before the correct level table and is loaded as the active file's level table. If this situation is not caught right away, then it is possible that the incorrect level table is modified and subsequently moved to the end of file. This creates a flip-flop type situation, wherein sometimes the elements may appear to have the correct levels and sometimes the elements may appear to not have the correct levels.
Further, if there is multiple reference attachments in the file, the problem can potentially be triggered for each of the reference attachment's level table, which could cause the problem of the file containing more than two level-tables which behave like the active file's level table.
To correct the problem, in 08.05.02.35 and later, the master level table with the lowest ID is loaded. In most cases the master table with the lowest ID is the correct level table as it should be the first one added to the file. So in 08.05.02.35, the level structure may appear correct, while versions prior will not show the correct level structure. MicroStation will also now detect if multiple level tables are associated with the active file and report a warning about the situation in the Message Center.
By always loading the active file's level table with the lowest ID, the "flip-flop" situation will no longer be experienced.
Further, a new level-audit application is delivered with 08.05.02.35. The level-audit application supports commands to detect and clear multiple level tables that are associated with the active file.
The problem is better handled in stages as outlined below.
Important: A backup should be made of the file set before any of the following operations are attempted.
The problem is normally encountered when the file is opened and the graphics do not appear correctly (drastic symbology differences which will be immediately visible if elements have been placed with BYLEVEL symbology when compared to office standards or the last time the file was viewed). Another possibility is elements not appearing to be on the correct levels. Again, in 08.05.02.35, these symptoms may not be apparent because of the (previously described) change in which the level table is loaded.
In version 08.05.02.35 or later, upon opening the file, MicroStation may report a message in the message center:
"Detected multiple level tables for master file (<file name>). Use level-audit application"
When encountering this message, the level audit tool will need to be used to clear the problem. To load the application:
Key-in: MDL LOAD LEVELAUDIT
*Optional: It may be a good idea to setup a log file.
Key-in: LEVELAUDIT SET LOGFILE <file name>
This will start a log file to capture the messages reported while using level audit.
To get a report of the current status of the active level tables use the following key-in:
Key-in: LEVELAUDIT REPORT MASTERTABLES
A MicroStation Text window should open and list message similar to the following:
MESSAGE: Reporting Master level-tables for file <Path to file>
MESSAGE: Master level-table id: <level table element number>
MESSAGE: Master level-table id: <level table element number>
--repeated for all duplicate master level tables found in file---
ERROR: Found n3 duplicate master level tables
MESSAGE: Finished Reporting Master level-tables for file
Note: This can be processed in batch (using Batch Processor) to get a report of multiple files at once. If used in batch mode, it is important to setup the log file.
If the file appears correct in version 08.05.02.35 or later:
Under most common situations, the lowest level table element ID is probably the correct one. If using 08.05.02.35 or later, this is the table that is always loaded.
Key-in: LEVELAUDIT CLEAR DUPLICATETABLES KEEPLOWEST
This will clear all duplicate level tables and keep the presumed "correct" level table. Refer to "Stage #3" for final procedures to correct the data. The text window will list a message similar to the following: MESSAGE: Deleting master level-table id: <Level table element id>
Run the report again.
To be sure all the duplicate tables are removed. The text window will list a message similar to the following:
MESSAGE: Master level-table id: <Level table element id>
MESSAGE: Found one master level table
*Optional: It is possible to replace the level table in a file from a level table from a backup file.
Key-in: LEVELAUDIT IMPORTBACKUPFILETABLE <file name>
This will clear all level tables from the active file and import the level table from a backup file. This is also good for files that no longer contain duplicate level tables but the current level table is not correct.
In some cases, after the correct master level table is in place and all other duplicates are cleared, some elements in the file may not be on a valid level. This would be most common if these elements were added to new levels created while the incorrect level table was loaded.
Key-in: LEVELAUDIT REPORT INVALIDELEMENTLEVELS
This will report all elements that have an invalid level ID and report a message similar to the following:
MESSAGE: Reporting Invalid Element levels for file <path to file>
ERROR: Invalid element levelid=<level id> - model=<model name>, element type=<element type>,id=<element id>
--Repeated as needed for all elements with invalid level id--
MESSAGE: Finished Reporting Invalid Element levels for file
After the element is reported, these can be corrected in two ways:
1. Select elements by the level ID and changed to the correct level:
Key-in: LEVELAUDIT SELECT ELEMENTLEVELBYID <level id>
This will select the elements in the file that all have the level id specified. From here common manipulation tools can be used such as "Change Element Attribute" to change the selected elements to a desired level.
2. Move elements to the desired level by level id:
Key-in: LEVELAUDIT MOVE ELEMENTLEVELNBYID <level id> <level name>
This will move all elements in the file that have the level id specified to the specified level name.
Also new to 08.05.02.3x is a built-in "level integrity checker" feature. The integrity checker checks the integrity of the level table header before writing level table information to file. If the integrity checker fails, then the following message will report in the message center:
"LevelTable Write Integrity check failed"
At this point, the level system will no longer write level information to file for the affected level table.
The operations performed, immediately prior to the integrity check failing, should be recorded and reported to Bentley Technical Support.
To clear the message, reload the file.
Product TechNotes and FAQs
MicroStation Desktop TechNotes and FAQs
Bentley Technical Support KnowledgeBase
Bentley LEARN Server
Bentley's Technical Support Group requests that you please confine any comments you have on this Wiki entry to this "Comments or Corrections?" section. THANK YOU!