At myBIMteam, we genuinely understand the frustration and setbacks caused by Schema Errors, introduced with the 2024.1 update of Autodesk software, because we’ve experienced them firsthand. Fortunately, through a great deal of time and research, we don’t just understand the problems—such as disruptive workflows, compromised data integrity, and hindered project progress—but we also have solutions that we are sharing with you. Think of it like tackling a contagious virus. Let us guide you through the containment process to equip you with a comprehensive understanding of Schema Errors and how to prevent them. You can also skip to the end of the article for the solutions.
Think of it like tackling a contagious virus – we’ll guide you through the containment process to equip you with a comprehensive understanding of Schema Errors and how to prevent them.
WHAT ARE SCHEMA ERRORS?
09/18/2024 Autodesk Update
Beginning in Revit 2024.1, released in July of 2023, users began encountering a new error, claiming internal conflicts with the file’s data. These errors seemed manageable with a simple ‘Continue’ command, and everything appeared unchanged. However, as more users encountered these errors, it became clear that this Schema conflict was creating instability in models, from the inability to upgrade existing files to crashes during opening or syncing, suggesting a widespread impact. In order to understand the solutions and next steps, first we need to ask, “What is a Schema,” and what is the conflict that Revit began reporting?
This data becomes baked into the very code of each file, down to the smallest component.
At their core, Schemas are data storage for additional Revit features. Built-in tools like eTransmit or Batch Print and separate plug-ins like Enscape, Ideate, or Kiwicodes, place these Schemas, or information structures, within Revit’s Extensible (secondary or outside the standard) Storage. These Schemas are then applied to every facet of the Revit model – components, worksets, parameters, etc. By creating and applying these packets of information, plugins can access, analyze, or modify aspects of your Revit model outside of the standard Autodesk delivery.
For example, the ability to update view and rendering settings live in Enscape, or the ability to manage and apply parameters across multiple families in Kiwicodes. This custom data is automatically added to every Revit file accessed by a user with these plugins installed, meaning this data becomes baked into the very code of each file, down to the smallest component. Extensible Storage Schemas are listed in the Purge Unused command, though we rarely see them available for deletion.
WHAT DOES A SCHEMA ERROR MEAN?
Now that we understand what Schemas are, the crucial question becomes: what does this error mean? In Revit, every object and all information stored within the file (user-accessible or otherwise) is given a unique string of code used as an identifier. The term for this is GUID (Globally Unique Identifier), and these are long enough that there are never, nor should there ever, be duplicates. Think of these as precise versions of the Type and Instance Mark parameters for an object. Then, extend the concept to every piece of data, every setting, and every tool in your model.
Our new issue introduced in the first major update to Revit 2024 caused clashes between existing data structures and those created by plugins. As the error message states, “The file contains data of schema “<Schema Name>” (from “<Plugin Creator>”), which has the same ID as a different schema already in memory. This tells us that we have duplicated our non-unique GUIDs between sets of storage in the model.
This is a serious drawback, as neither Revit nor the given plugin will be able to accurately access or analyze the information stored within the Schema – trying to read two things at once would break the process. As a result, the error continues: “If the file is loaded, the existing data will be erased from the model.” As is common (and in this case, correct), Revit’s determined course of action is to delete the existing information in favor of the newly loaded Schema. This dire language rightfully worried Revit users, as anything being erased from your model could be catastrophic for everything from model integrity to accurate project delivery.
WHY ARE THERE SCHEMA ERRORS?
This leads us to another question: Why are conflicts with these Schemas arising? If a user had been working in a project file, happily using their plugins in base Revit 2024 (or 2023 and 2022 for that matter), why did Revit 2024.1 suddenly cause these complications? Unfortunately, this part of the history of Revit 2024.1 is murky, full of technical language and behind-the-scenes efforts by Autodesk. Within the release notes for 2024.1, Autodesk announced the update focused, among other things, on fixing “…an issue where opening an upgraded file containing Schema that conflicts with Schema in the existing session will delete elements…”
TECHNICAL CHALLENGES BEHIND SCHEMA ERRORS
So, it appears the update was meant to fix a previously identified conflict between existing and newly opened data. Specifically, they call out upgraded files – a point to remember for later. Ideate Software, creators of a spectacular suite of high-powered management tools, was the first to report on the problem. In their ongoing blog posts, they highlight concerns called out in the initial Autodesk Forums after the release of 2024.1.
The issue was most prevalent in models upgraded to 2024.1 for the first time.
Through extensive group analysis and collective efforts, it was determined that these changes to Revit’s API (Application Programming Interface or the method computer programs use to speak to each other) were unexpectedly causing conflicts in existing Schemas. ElementIDs, or the user-facing version of a GUID for content in the Revit file had transitioned from 32-bit to 64-bit storage systems within the software in the initial 2024 release. This change, coupled with the revision in the 2024.1 release notes, particularly for Schema storage, resulted in a mismatch between existing (Int32) and updated (int64) ElementIDs. Consequently, the issue was most prevalent in models upgraded to 2024.1 for the first time. Files created from scratch or upgraded in 2024 did not seem to present the same problems, at least initially.
Users began noticing this Schema Error not only when opening the file but also during synchronization, BIM360 / ACC uploads, or even modeling tasks like Curtain Wall modifications. Troubleshooting persists to be difficult because users would experience errors differently from others, even when working on the same project. Often, the error would not present unless a file was Audited, meaning this conflict was behind the scenes. However, the most common symptom of the warnings, regardless of when and how they occurred, was model instability, inaccessibility, and crashing.
Autodesk released several Helpdesk articles regarding solutions; these boiled down to rolling back your models and software to the initial 2024 version when possible. Unfortunately, due to the months between 2024.1 and this issued set of steps, rolling back a model and re-upgrading would mean losing a great deal of work – a burden most users and companies could not afford. Some found the noted Schema was from plugins used in years prior, not even currently – because this information is baked into the model, these warnings could pop up any time a model was upgraded into 2024.1.
Any time this file is linked elsewhere or opened to harvest a detail or custom family, these Schema conflicts can transfer to the new file.
This leads us to the crux of the problem. As mentioned earlier, when loaded into your Revit session and model, the Schemas attach themselves to any and possibly every piece of information within the file and session. This means that any time this file is linked elsewhere or opened to harvest a detail or custom family, these Schema conflicts can transfer to the new file.
We at myBIMteam were building updated Project Templates and Standard Detail files for a client when these errors were first discovered. This error being present in a file meant to be accessed every time a new project began or daily when users wanted to pull firm-approved standard content was a catastrophic prospect.
SELECTIVE SOLUTION
That was quite a lot of doom and gloom, so on to the most important topic: what are the solutions? As stated previously, Autodesk’s initial and continued workflow for a file experiencing these issues is to recover a previous version that was never opened or updated in 2024.1. In September, they released 2024.1.1, an update directly targeting these complications. Within the notes, we see they focused on challenges relating specifically to addons and upgraded models, the two items discussed here.
Those with corrupted files are left searching for options, which we have listed below.
It is crucial to note that 2024.1.1 stops the issue only for newly updated or created models. It does not rectify or impact any model that was upgraded or created in 2024.1. So while the problem has been curtailed (the newest update, 2024.2, notes that the issue has been determined to be resolved) for future work, those with corrupted files are left searching for options, which we have listed below.
LATEST SOLUTION + 3 BEST PRACTICES FOR PREVENTING SCHEMAS
Between utilizing add-ons such as KiwiCodes’ Extensible Storage deletion tools, or PyRevit’s Schema Remover (Wipe) and old-fashioned Purging, Auditing, and manual testing, myBIMteam invested a great deal of time to create a workable plan of attack. Despite the best efforts of several team members, we were unable to consistently and permanently remove these errors from a file.
Thus, we came to a last resort: directly contacting Autodesk. We have used this method for the two critical files referenced above and found their solution process to be simple, effective, and, so far, permanent. However, it is important to note that they are capable of cleaning files one at a time, and only when project teams are not working.
Though this solution exists, it is only permanent if caution and diligence follow.
- Still, a word of warning! Though this solution exists, it is only permanent if caution and diligence follow. All content upgraded (families, sheet files, details, projects, etc.) in 2024.1 must be thoroughly quarantined. By ‘quarantine,’ we mean these potentially contaminated files must be scrubbed from all locations your staff may interact with. Company drives, resource folders, and project folders should all be carefully reviewed to ensure no traces of a schema-infected file. We feel that treating this error as if it were a virus will provide the care needed to avoid any reintroduction.
- Once files have been removed from easily accessible locations (this would include both server-bound project files as well as BIM360 or Construction Cloud content), we next recommend appending notes to the end of these files, such as ‘_SCHEMA’ or ‘_ERROR.’ This makes certain that even if a file must be retained digitally, it is clear to future users that it shouldn’t be opened. As indicated earlier (and observed by us), copying something, such as a detail component from an ‘infected’ file, into your fresh version can reintroduce these Schema Errors, regardless of which version you are working in. A last step, have users working on the previously infected file delete old local copies of workshared models. This way, working with the new version will secure a fresh start.
- Lastly, it is essential for all project team members, including consultants, to upgrade to at least 2024.1.1, preferably 2024.2. This demands time and effort, but the initial cost will save you headaches down the road should these Schema Errors return.
Our friends at Ideate Software continued their blog through the process and provided what appears to be the final summation of this saga. We thank them and the generous folks on the forums linked here for sharing their time and observations with the community.
HELPFUL TIP: UPGRADE WITH CAUTION!
In closing, here is a piece of advice for the future: upgrade with caution! While the newest tools, workflows and improvements are enticing, often it is best to wait before upgrading. Our typical recommendation to clients is to upgrade once the first Service Pack (2024.1 in this case) is released, as this will typically resolve any initial version issues. However, even this method is not foolproof, as this blog post should have made clear. So, check the forums, contact your BIM Managers, and archive those models before making any software changes.
