AutoPLANT Issue - Lost Line Number and Damaged Schema

Last week, I was working on an issue with a user that I feel I should share with ours. The user had made a previous service ticket for a different issue which we had fixed the day before. He then gave me a call to let me know everything with that issue was working now, but one of his drafters noticed that the only Line Numbers in any 3D model that he could see were the ones that he created within the last day. There was 400 plus line numbers missing from the project.

The first thing we decided to do was to review the database for the Line Numbers to see if they were still listed in there. After reviewing the tables, we found that all the Line Numbers were present in the Process table, but not in the TAG_REG. After finding this, we then went into a model and attempted to run a Repair Relationships with the hopes that it would pull the line numbers back in. While running the repair, it found several line numbers that were missing. We then went to add them back into the project, but got an error claiming that AT_PROCESS was not defined in the TAG_TYPE.dbf. We next checked the database again to look for the TAG_TYPE table. This table is actually part of the schema, but this project had the schema in the Project database. The table appeared to be fine and did have the AT_PROCESS defined.

We next went into Project Administrator to see if everything came in ok in there, but we discovered that the TAG_TYPE table wasn't being pulled nor was any other information that was coming from the schema. It appeared as though the schema database information wasn't connected to the project. The odd thing about this was that the project showed the connection to the schema and it appeared to be working fine.

From this discovery, we figured that there was something in the schema tables that was damaged and didn't allow the program to properly connect. Because there was no backup of the schema, nor were there any customizations done to the schema, we decided to try pointing the project to a working schema. What we did was locate a schema.mdb from another project. Then we copied that file into the Projdata folder of the troubled project. With that done, we then loaded up Project Administrator again and changed the connection for the Schema to point to the new schema.mdb rather then the Project database. One thing we noticed was that the connection string is extremely long compared to a project that was created using an Access schema, but after checking all the connections and tables, it appeared to work great. We then tested out adding a Line Number which worked this time.

With the Schema working again, I decided that it would just take way to long to go into each drawing and run Repair Relationships on them, just to add the line numbers back in. I decided to try another possible work around to get those line numbers back into the project. Basically, we took all the Piping models and exported them out to another project. During the export process, we made sure to update all the tags. Afterwards, we checked to see what Line Numbers were available to us. It turned out that all the Line Numbers that had been in the troubled project had come over with the drawings. We then imported those drawings back into the troubled project and told the import wizard to Override all the documents so that it would have to re-write the information back into the project rather than skipping over any existing ones. This worked in getting all the line number back into the trouble project.

To what caused the loss of the line numbers, the only thing that I could see was that the Project's Schema most have been damaged, which in turned caused some errors in the project tables that rely on the Schema for information, such as the TAG_REG table. Another complication that existed in this issue was that the Project was a Multi-Proj project with only one of the projects using the schema in the project database. The rest all used their own schema.mdb files.

In the end, the issue was resolved by reconnecting the project to a new schema and then exporting/importing the piping documents to force the database to rebuild the relationships.