2024.1 Update causes new Schema errors

[GlynnisVP]

There's been a lot of chatter about the Schema error that was landing in a post about What's New in 2024.1 so I took the good suggestion from @RobDraw  to start a new thread here.

What is a Schema?

I welcome other people's input on this, but from my perspective, a schema can be best thought of as a blob of Revit metadata, held in Extensible Storage workset, that has a unique GUID. This blob of data is most often used by 3rd party developers but is also used by Autodesk (or companies acquired by Autodesk). The structure of that data, per each GUID, needs to be the same. If a developer alters the data structure, then a new GUID is needed to avoid the error.

What causes a Schema error?

In order to experience a Schema error, you need to have two files (or a file with a linked file) that have the same schema GUID but with a different data structure. Whichever file is opened first 'wins' within the active Revit session. This makes solving these problems REALLY hard because the file that displays the error is not necessarily the file with the 'problem' schema. It's also why this problem seems to be squashed sometimes and then resurface later. If you only ever open one Revit file at a time within a session of Revit, you'll never see the error.

What's the New Problem

The new problem seems to relate to Revit files that are upgraded to 2024/2024.1. The 11 July Revit 2024.1 release notes show that in there were changes made to the API to try and fix an outstanding schema condition. It feels like that change may have created some new conditions. We have an open case with Autodesk on this issue.

There are three new Autodesk solutions that suggest that to avoid the problem you need to upgrade your pre-2024 files one at a time to avoid a crashes, deleted data, or the error dialog prompt.

• https://help.autodesk.com/view/RVT/2024/ENU/?guid=GUID-38030A32-0460-4A2A-92D8-B698C0B01161
• https://help.autodesk.com/view/RVT/2024/ENU/?guid=GUID-40B0224D-9925-449B-84D0-8241EA15849A
• https://help.autodesk.com/view/RVT/2024/ENU/?guid=GUID-A8A5E4FD-8671-4B00-B3E6-CB4707D80744

I am hopeful that these are just interim workarounds to a problem that will be fixed. We have not changed our Ideate Software schemas and yet our customers are experiencing this issue.

[RSomppi]

---

@HVAC-Novice wrote:

Your statement only makes sense if Autodesk would refund us the subscription if a new version is botched.

---

Okay. If you like flying by the seat of your pants and not preparing for possible issues, that's on you.

My statment makes sense for much more than upgrading but, in the case of upgrading, it is possible that errors exist in your project before an upgrade and those new features and/or error checking can cause issues, sometimes major ones like what happened here.

[RSomppi]

---

@randy_lmn wrote:

What I am going on about is making sure Autodesk provides the services we pay for, and in this case, their product offering has been cut for this year and as such prices should reflect that.

---

I'm going to ahve to disagree in this case of upgrading projects.

[HVAC-Novice]

Did you actually talk to Autodesk support about this, or how do you get to this opinion?

I talked to support and they reviewed my files. The schema error wasn't caused by something wrong in the older version file or something the user did wrong. It was caused during upgrading. It also didn't appear right away after upgrading. This isn't something you notice right away and can then relatively easily backtrack. 

Best I can learn from this is to wait close to a year before upgrading. Being only 1 year behind shouldn't prevent from using modern OS/hardware but hopefully gives me a somewhat stable version. Being 4 years behind will have other unintended consequences. 

[randy_lmn]

I can respect your and your office's practices on updates.  We strive for the middle ground ourselves.  Sticking to the bitter end doesn't seem like an industry norm on my end. 

As far as the errors prior to the update....  I guess if you haven't been in or actively testing real projects in 2024, you wouldn't know what we are talking about with the schema errors.  

In a nutshell, you can have a completely brand new out of the box file, completely void of errors, model elements, and schemas.  If you open a single file that has two schemas with the same GUID within the same work session, that empty file you haven't even touched will now have that corrupt schema.  You don't have to load the family in.  You don't have to load a link in.  Any schema in any open file is now in all open files and transferred through the journal file.  Because Autodesk changed from 32bit to 64bit schemas, app developers who weren't using that field (which many reliable and reputable ones are not), that field was filled in by the new Autodesk API.  Overtime as those schemas that transfer between all consultant files and families through the life of the project start to interact, my add-in on my side that filled in that 64bit guid is the same guid that my structural consultant has from a different add-in.  Put them together and boom, loading your linked model caused half your model to disappear without any means of auditing, validating, or preventing deletion of those items.  So, this is not really on end users.  This is a fundamental flaw that exists within every file and one day, it could bite you with how Revit has changed the API.  

Previously, I've only seen one schema issue pop up between Trace-It and Enigma.  The schema utilities provided by pyRevit or dynamo could address and resolve those relics from previous versions.  Not the case here.

Unless you are committed to rebuilding your entire family library from scratch, or rather than upgrading models, you choose to rebuild the entire model from scratch, everyone will inevitably go through this.  Have fun doing that in 2028 when you finally reach Revit 2024.  

[RSomppi]

---

@HVAC-Novice wrote:

Did you actually talk to Autodesk support about this, or how do you get to this opinion?

---

No, as a model manager for 15 years, there are things I've learned from experience and observation of these boards. The fact that you think it is an opinion tells me this part of the conversation is done. People get upset when I have valid points that they never considered.

Good luck.

[RSomppi]

Thanks for CADsplaining the obvious.

Every office that I've worked for has had versioning dictated by 3rd parties. When the option is available, we will start a project with our latest operating version AND STAY ON IT until necessary. Upgrading has always been done reluctantly and with care. It's just best practices, IMHO.

[randy_lmn]

Wish I could offline this.  I genuinely was trying to provide helpful information, not just to you, but to anyone who hasn't yet observed this very serious issue as you were asking about pre-existing errors being a possibility of the issue.   That is not the case for anyone experiencing this issue.  I think anyone contributing to this forum and post has taken every precaution to update methodically and with care.  We are all professionals here.

[RSomppi]

My statements are on the subrect of best practices for upgrading, not just for going to ‘24. My point is that at any new version there is a chance that something unexpected can happen. My experience with working in a team environment over many platforms tells me that stuff happens. Revit has had some issues with upgrading before and sometimes users have suffered a lot because they “couldn’t” go back. Most of them blamed Autodesk. Some of them got very angry when it was suggested that they could have avoided the issue with just some planning and testing before going all-in.

I’m not disagreeing with this being an extreme case and feel sorry for the folks that have lost work and time dealing with the issue when they upgraded without a backup because they never had an issue before. 

AutoCAD has a similar history. Some releases were bad and not worth using. Luckily, those files are backwards compatible. Upgrading with any program that is not, is risky at best. Project busting at worst.

(I don’t need someone from Autodesk to tell me their opinion about that.)

[GlynnisVP]

Hello everyone,

Since I began this post some months ago I thought I would try to wrap it up, to the degree possible. We have just posted what is hopefully our final blog on this topic which covers: 

• The new Revit 2024.2 update, and its relationship (none) to this schema topic
• Tips for fixing problem files relative to this schema topic.

I hope this information is useful to the community.

https://ideatesoftware.com/blog/revit-version-2024-2-and-the-schema-errors

Best Regards,

Glynnis Patterson and the Ideate Software Team

[Karol_Piroska]

@GlynnisVP,  thank you for sharing. I'd like to add that this might work for some files, but it will only "pretend" to work for others. I tried everything possible myself with Autodesk support and some files appeared to be healthy, until I run audit when opening these files and I got the schema error message again. The only "solution" for now is to send these files to Autodesk, save families from these corrected files and replace your library, since it takes one file/family to ruin it all again.

[GlynnisVP]

@Karol_Piroska - one thing to bear in mind is that if the problem resurfaces in a 'cleaned file' it is very possible that the problem file is not the one where the problem schema exists. This is why this entire thing is such a mess. The schema error warning only indicates that the file where the 'error' displays has a schema that is different (not necessarily wrong) than the first document opened in the session. That file can be a linked file or family file that was opened first in the Revit session. It's extremely difficult to discern which of the files has the corrected schema GUID. 

That's why closing Revit between each 'fix' is so important.

But, by all means, do send them to Autodesk for a repair!

[Karol_Piroska]

@GlynnisVP , what I meant is that sometimes a file appears healthy, without a schema conflict message when working with the file, but if you open it with audit (in a new revit session), the schema conflict message might appear just then. I spent hours going through all files, opening and closing revit each time trying to find all affected files. 

[HVAC-Novice]

When R2024.1.1. got released, I was under the impression that only was a temporary fix and the real fix still is coming. Based on what I read here, R2024.2 didn't address schema errors.

Will we still get a real fix? Or is that something Autodesk ignore and then hope R2025 will fix? 

[josephsWYW3U]

@Karol_Piroska 

Can you SEE the Schema when purging, or are you just keying off of when you receive errors? We had a similar experience where we were able to trigger the error only when auditing as well. 

Ultimately, the fix requires locating where the schema conflict is coming from. It could be any Revit family, or orbjec tin a file conflicting with a linked model element. If the culprit is not identified, then it will keep coming back.

To help identify schema errors, we found that the UNIFI Schema Cleanup tool helps profoundly. It's a plugin that when installed runs in the background, and makes Schema's "visible" and "Purgeable" when they're otherwise invisible. This helps a lot with identifying which objects may be infected as you can simply run a purge, and see if the schema conflict is listed. If it is you can purge it if you like, save the file (the Schema will come back), purge it again, save, and the Schema is successfully removed IF you've identified the culprit and delete the scehma from there as well.

[Karol_Piroska]

@josephsWYW3U , thank you, I'll try the UNIFI schema cleanup.

I was advised by Autodesk to use Revit database explorer to try to find the issue as I only had one file where schemas were listed in the Revit purge tool. Unfortunately the Database explorer tool is not able to access families and the support team didn't want to say what the issues were in files that they repaired. 

[GaryOrrMBI]

The problem file...

The problem family...

It's neither one...

The problem is how Autodesk implemented the Schema concept itself.

Schemas should reside within the project and/or family files themselves and not cross over between them. They should be read in to memory the same way that everything else that is file dependent is read in.

If I have family A in project 1 and have family A with a different definition (redefined after loading it perhaps) in Project 2 and open both of the projects in the same session of Revit, the files do not get corrupted, things do not get deleted, the family definitions do not get modified or deleted, etc.

Why not? because they "live" in separate memory spaces. Everything stays compartmentalized as it should. But. for some reason, the developers wrote a system that stores what should be file resident as application resident, even though creating a schema and storing information within it is done to store information in specific objects within specific files...

They made the problem even worse when they shifted the method of deleting schemas within the API (I know, this is not the API forum) making it so that developers can't delete schemas from files and from memory properly...

This is the REAL problem, and that is what needs to be fixed. Not our files, but the base implementation of the concept.

-G

[RSomppi]

---

@GaryOrrMBI wrote:

This is the REAL problem, and that is what needs to be fixed. Not our files, but the base implementation of the concept.

---

Wouldn't that "fix" require a rewrite from the ground up. Seems a bit of a lofty expectation.

---

@GaryOrrMBI wrote:

The problem is how Autodesk implemented the Schema concept itself.

---

Are you sure it was Autodesk?

[GaryOrrMBI]

---

@RSomppi wrote:

---

@GaryOrrMBI wrote:

This is the REAL problem, and that is what needs to be fixed. Not our files, but the base implementation of the concept.

---

Wouldn't that "fix" require a rewrite from the ground up. Seems a bit of a lofty expectation.

---

@GaryOrrMBI wrote:

The problem is how Autodesk implemented the Schema concept itself.

---

Are you sure it was Autodesk?

---

It very possibly could require a ground up rewrite... I know how tough it would be for a company with such a limited number of developers and such a limited amount of funds available from such a small user base buying their product to do but, this simple background change (Element Id data storage type) causing such a large issue is simply the proof that something needs to be done before we end up with a cascading failure at some point in the future (imagine pulling a project out of your archives to perform a remodel on it and... you can't because this whole thing was 3 years in the past and it's forgotten about and no one knows how to get around it anymore, what then???).

Am I sure it was Autodesk?

It doesn't matter who wrote the initial (or even underlying) code... Autodesk is who we buy (more like lease these days) the software from and are ultimately the ones that are responsible for the product.

-G

[RSomppi]

I think your opinions have taken this far away from the topic. You should address your concerns elsewhere and possibly directly with Autodesk. There's not much that can be offered on that front in this user help forum. Try the IDEAS forum.

Good luck.

[robertas_suminskas2]

That solutions can be if Autodeks limiting for user who want to fix. One thing I can tell that they can’t handle by themselfs and doesn’t want help from user as well.

also I don’t blame developers. Problem is marketing to push new Revit every year without finish product. Developers are working under presure to meet deadliness and make happy stakeholders.