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.

[parley.burnettMZ2ZR]

@GlynnisVP This has caused some alarm for us at Guardian also. Is there any word from the factory yet on this? Seems it is on them to fix.

We've used just one string field and store everything we want in json format within that single field. It gives us flexibility to adjust json structure as we enhance features, without having to manage schema versions. All good until 2024.1.

So, it seems there is more to it than just using int fields to store element ids. 

We heavily depend on the schema used to store project cookie guid, so if that is failing it might be interrupting user's flow very often.

[GlynnisVP]

@parley.burnettMZ2ZR - we are updating our case status here for reference: https://ideatesoftware.com/blog/important-information-about-revit-2024-1-and-new-schema-errors

The latest input was that they have acknowledged the problem and indicated that it would be addressed in the “upcoming releases of Revit. However, at this time, we do not have a timeframe as to when this fix would be available.”

[Sahay_R]

That's a crying shame - 2024.1 has some cool enhancements in it. 

This is a good example why, as an organization, we don't rush to be the first to install and wait for glitches like this to get ironed out.

I hope that this is resolved fast!

[parley.burnettMZ2ZR]

Really appreciate the update. We're doing what we can to help bring awareness to the issue also. If we can help with anything, let us know. Thanks @GlynnisVP!

[GlynnisVP]

Update on this issue...

• Our Ideate Software schemas, which do not use Element Id fields, are sometimes being altered during the Autodesk Revit 2024.1 upgrade process.  This change results in our schema having no fields, where previously it did. This constitutes a change to our schema definition, thereby triggering the error conditions.
• We don’t use Element ID fields in our data storage and therefore 2024.0 does not cause Ideate Software a problem during upgrade but may cause issues for other 3rd party developers due to underlying change to Element Ids in version 2024.
• Until this problem is fixed we cannot recommend upgrading to Revit version 2024.1.

Autodesk  - We appreciate that you’ve acknowledged this new problem but do not have a timeline for fixing it. Please fix this problem ASAP so that our mutual customers can safely upgrade to 2024.0 and 2024.1. The cardinal rule on schemas is that they should not be altered. Please do not touch our schemas. We would welcome a call to discuss this further.

[parley.burnettMZ2ZR]

@Anonymous Same!! We need this fixed ASAP. We do not use Element ID fields also.

[RPTHOMAS108]

I don't know if you have some new issue or not regarding what is being described.

Schema conflict errors have been around since extensible storage was introduced and it was always due to a developer not being disciplined about how they upgrade their schemas between versions. They would often attach new fields to them or even change seemingly innocuous things such as the documentation field between versions but keep the same id. In the end however if you change the schema you have to change the id associated with the schema. It is kind of a common theme in the API forum and I've lost count of the number of posts that state that fact. Once you've put it out there it is too late, it will cause problems eventually.

So the correct way for a developer to approach this is to create a new schema with new id and transfer all the values over from the old schema (not change the same schema between versions).

That being said there was a recent issue where ElementIds in Revit changed from 32bit to 64bit. So the schema was seen as different between versions causing a conflict (that I think is resolved).

However the way in which the conflict is now dealt with is likely the reason that some developers are now seeing this i.e. they perhaps already had an inherent problem with differences in their schema between versions but previously such conflicts led to the element being deleted (I don't think that is ideal behaviour and would rather get the dialogue than have elements being deleted during upgrade). Note that if they had attached their schema to an element that could not be deleted by the API such as project information singleton then I suspect they would have instead got the dialogue regardless of the Revit version.

I made the same mistake with schemas in 2012 version got the same message in 2012 but somehow have managed to avoid causing the message since 2012 (except for the recent ElementId aspect noted). Actually I think if memory serves I didn't get the same message in 2012 I instead got an abrupt end to the Revit session. I think they introduced the message a couple of versions on, but it demonstrates the importance of getting it right.

I don't know what any good any of the above I've written is to an end user however, they just want to use Revit without the schema conflict dialogue or elements going missing I suspect.

[dfoth]

@kimberly_fuhrman-jones 

Can you please pin this post to the top of the Revit Architecture Forum board? The schema issues that are affecting Add-in developers will directly contribute to many users not using Revit 24. Autodesk needs to make the fix a priority.

[parley.burnettMZ2ZR]

@RPTHOMAS108 Thanks for the message. However, we have never changed our schema. We store everything in a single string field and store everything in JSON format.

[randy_lmn]

We are seeing the schema conflict in as well and cannot open or work in a file without "continuing to load".  

Unfortunately, we are also seeing there is a consequence in doing so where modeled elements are being deleted everytime we do.  This schema conflict also seemed to spread to linked models and as a result we can no longer rely on our links.  

So far we have 3 schema conflicts.  Guardian, Enscape, and Ideate which are three add-ins we rely on.  Our team rolled our Revit version back to 2024.0.2, cleared cache and are opening with all linked worksets closed, but even loading in some of the families that were completely deleted, forces the error to pop up again.  So it seems the schema issue is also affecting many of our families.

[RPTHOMAS108]

If you are saying you've not changed anything at all associated with the SchemaBuilder between versions then I agree that seems like a new issue.

[GaryOrrMBI]

A quick note to this: it isn't just the independent add-on developers that have created a conflict with different schema versions.. There was an Adesk structural plug-in that did the same thing a couple of years back. Heck, I just did a quick query and found 7 Adesk schemas in my current project. I didn't put any of them there, I didn't ask for any of them to be placed there... I mean, I've never used PnID yet:

Schema Name: ResultsAccess | Vendor: ADSK
App GUID: 7ea55299-97fd-4ac4-9631-bee440aab8ac | GUID: 4fae6fe4-671f-4819-ac11-330b36d080f2
Field Name: ListOfGUIDs | Data Type: Array

Schema Name: PnIdRevitAssociatedProjectInfo | Vendor: ADSK
App GUID: 00000000-0000-0000-0000-000000000000 | GUID: 6c18dbbc-9576-4a9b-ad85-0246705dd891
Field Name: PnIdAssociatedProjectId | Data Type: Simple
Field Name: PnIdAssociatedProjectImage | Data Type: Simple
Field Name: PnIdAssociatedProjectName | Data Type: Simple
Field Name: PnIdAssociatedProjectRegion | Data Type: Simple

Schema Name: ResultsAccessDataStorage | Vendor: ADSK
App GUID: 7ea55299-97fd-4ac4-9631-bee440aab8ac | GUID: 240438fa-55b3-42bc-ad03-128aac6fce5c
Field Name: MainGUID | Data Type: Simple

Schema Name: InternalSchema_Data_Version_4 | Vendor: RPCA
App GUID: 00000000-0000-0000-0000-000000000000 | GUID: f4c29204-8690-4b24-9af3-25c2e22f4701
Field Name: IsZipped | Data Type: Simple
Field Name: TheData | Data Type: Simple
Field Name: VersionNumber | Data Type: Simple

Schema Name: CoefficientFromTable | Vendor: ADSK
App GUID: 00000000-0000-0000-0000-000000000000 | GUID: 1b022a2b-5722-4787-928a-4f29ca9d8811
Field Name: PipeFittingKFactorTableName | Data Type: Simple

Schema Name: ResultsAccessRevitDocumentId | Vendor: ADSK
App GUID: 7ea55299-97fd-4ac4-9631-bee440aab8ac | GUID: 62c7a40c-09f4-4db7-af74-c0df34c27b8e
Field Name: DocumentGuid | Data Type: Simple

Schema Name: FamilyBrowserStatus | Vendor: ADSK
App GUID: f86d4a1d-1b8f-4bd1-97e8-2c593bf4d419 | GUID: 99445e32-4a81-441e-9879-4d4cfdef7aaa

But this has nothing to do with the add-ons or potential mistakes made by their developers, this is a change to the underlying system that missed a beat in thinking it through.
They just need to stay on top of building a fix, as I'm sure they are... But this should be made a priority across the board if it hasn't already...

[kimberly_fuhrman-jones]

@dfoth, 

I do not have that power on this forum, but I have asked @lim.wendy to assist. Yes, this is a critical issue and our teams are focused on getting a solution. We will keep you posted!

[josephsWYW3U]

This is sort of an oversimplification of what's happening, and regardless of how it originated (bad practice by an app developer) Autodesk needs to provide a solution for when this occurs. We've encountered issues in previous releases through no fault of our own (linked models from consultants creating conflicts) and need a way to fix the error.

[mhiserZFHXS]

We also just had this happen to someone in our office. We only use a handful of add-ins and they are all big names (Twinmotion, IMAGINiT, and Bluebeam).

Hate to keep piling on, but Autodesk really needs to get this solved ASAP.

[RPTHOMAS108]

Agreed but at the same time it needs a well considered response.  A well thought through 'what are the implications of what we change' response, give them time to look for it. I don't have any inner knowledge of what the fix did or didn't do but my over simplification is based on the following facts:

1) That dialogue is nothing new I had it years ago (browse the internet you'll find it).

2) Someone noted the 2024 issue on the API forum 5/9/23 (US), Int32 vs Int64 ElementId fields came up as part of that since in 2024 they had changed to Int64, so that was the obvious suspect.

3) As part of (2) it was noted that elements were being deleted (what would be the reason for that)?

4) A fix was issued for (2 & 3) and suddenly the elements being deleted were no longer being deleted but also those not experiencing the dialogue are now reporting it.

So I draw my conclusions as to the before an after behaviour of the fix and what that points to. Perhaps there is something else going on however, who knows. 

The change to 2024 likely would have caught out everyone big and small. There was nothing really the developer could have done to avoid it, I think that was my sentiment above (some would have had that pre-release period of testing). 

That being said it was kind of a hard thing to spot for a developer during normal testing of their app. They would have had to have the session open with old and new schemas loaded. Use the same session to upgrade an old file whilst a current one was already open. That is the kind of thing an end user finds more easily therefore in normal Revit operation.

What could be the fix? That I'll leave to others but it isn't deleting elements or preventing the use of extensible storage. I'm kind of passionate to avoid the whole 'custard kills people, should we still make it'? approach to life. 

[josephsWYW3U]

I generally agree. I see why it was not caught, and we need storage schemas. I'm not attributing blame here, they're necesary and tricky, however I AM glad to see this being escalated so it can be addressed once and for all. Schema's and our inability to address their conflicts have long been an issue in Reivt. We previously encountered this error with a conflict between "TraceIt" and "Engima" schemas (first reported in 2015). It hitched a ride on a consultant model, and caused irreparable damage to our model which required rolling it back and considerable downtime and loss of work.

The crux of the issue is that the Schemas are not visible nor purge-able from a model. We were eventually able to address the problem, but it required a plugin that made the schema visible, a purge, save and then another purge, and save. PyRevit couldn't delete it, Dynamo couldn't delete it. It's just something that existed and couldn't be rectified.

The inability to delete schema's was the topic of discussion 2021: https://forums.autodesk.com/t5/revit-api-forum/not-able-to-delete-extensible-storage-schema/m-p/1201....

I'm wondering if their fix to address this issue inadvertently created this conflict? Here's hoping we can get a fix once and for all.

[RPTHOMAS108]

Yes...I don't know anything about the inner workings of Revit, however it is more likely than not they use third party components over which they only have so much influence. I point to the long history of this as to how easy a fix can realistically be. The term 'Fix' is also so subjective: Was it originally fixed at inception? When did it go wrong? Did it go wrong as the result of another 'fix'? Sometimes people ask for safety nets in how things work but that adds a layer of complication and increased complexity has more unforeseen possibilities. Dangerous to cross the road so we add a bridge but the support to the bridge blocks the view of the driver to a junction etc. 

They (Autodesk) can only really satisfy themselves that schemas work in a stable way i.e. that if they set out a design pattern which a developer sticks to then that developer will not create a problem. They can't entirely allow for all the ways a developer might do things wrong or the implication of a developer not following a pattern. Likewise if a developer follows the pattern as set out but an error is still occurring then they are right to ask Autodesk for a resolution to that. That to me is the relationship, everyone has a part to play.

The crux of that unwanted dialogue message specifically is that they (Autodesk) can't say with certainty what impact there will be to an add-ins functionality if it can't read the schema in conflict. They can only inform you as a user of the situation as it is i.e. there are two forms of the same schema so it was deleted (because a conflicting schema can't exist in memory) and any add-in relying on that may not function correctly.

Perhaps the solution is for Autodesk to have an option in the settings to not show such warnings. The problem still exists but the user doesn't want to know about them. That is probably the way forward, a kind of opt out to the dialogue thereby only experiencing it one time for each user per conflicting schema or not at all. We have those dialogues that say 'don't show me again' so there is precedence for that.

[xuan_chen]

Sorry for the delay in directly responding here as we have been working to investigate all the cases of this issue and the fix. We wanted to let you know how important we view this problem and to help answer questions and clarify what is happening. It shows the problem is caused by a mismatching schema (stored in a global data context) and entity(stored per element).

As some of the threads have already noted: there was a major change since Revit2024 that Element id is now tracked by Int64, underlay affects the schema’s identical even there is no explicate modification of a schema. That’s why you may receive the “schema conflict” warning even if you(or your addin) haven’t changed anything. Consequently, when the entity cannot locate its schema/ or happens to locate an incompatible schema, unexpected results will happen(including but not limited to crash, eliminating the holder element, etc.).

We are proactively working on this issue as our top priority to make sure the consistent alignment between Schema and Entity, however, considering the RVT format compatibility, we cannot resolve all the problems in one shoot.

Finally, I want to sincerely express my appreciation for your patience. We keep monitoring and tracking all different cases, make sure we are fully understanding the issues in the field, and provide a feasible solution instead of making the situation even worse.