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.
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.
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.
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.
What plugin did you use to make schemas visible so that you could purge them? Thankfully our team only has one project in R24.1 but the schemas are starting to become an issue because the client is using a precast Add-in in their model.
What plugin did you use to make schemas visible so that you could purge them? Thankfully our team only has one project in R24.1 but the schemas are starting to become an issue because the client is using a precast Add-in in their model.
InviewLabs CleanProject. We received it from the people at UNIFI, which I believe is formerly InView labs. It's a plugin that runs in the background automatically, and allows the offending Schema to be visible when purging.
Per the update this morning, I'm not certain that it will fix this issue however. It also does not address the issue of conflicting schema's re-loading if they're in a link or a family, but it does make it much easier to identify which files are the problem.
InviewLabs CleanProject. We received it from the people at UNIFI, which I believe is formerly InView labs. It's a plugin that runs in the background automatically, and allows the offending Schema to be visible when purging.
Per the update this morning, I'm not certain that it will fix this issue however. It also does not address the issue of conflicting schema's re-loading if they're in a link or a family, but it does make it much easier to identify which files are the problem.
Feel your pain and appreciate the meticulous effort - cheering you on!
Feel your pain and appreciate the meticulous effort - cheering you on!
Thanks for your efforts @xuan_chen
Given these schema conflicts are not new is it worth looking at how such things could be responded to differently by the UI. Rather than having a task dialogue that stops the load could there instead be a balloon tip that notifies upon load that is then logged somewhere and only a modal warning of it before saving/synchronising (when corruption is cemented)?
I think inherently the problem is the problem a classic two into one doesn't go. The lessons are still being learnt one developer at a time regardless as to the recent ElementId issue. The track record unfortunately demonstrates that the level of learning will not improve so perhaps overall it needs thinking about differently (a UI solution).
The following I assume are the kinds of document corruptions that could occur. So users would need to be vaguely aware of what the associated add-in is doing and so gauge how much they can live with it having a bad schema:
A) You have an add-in that stores information per element and the user has stored a lot of information on elements for this schema. If you open a document with all that information but there is already a conflicting schema present then all that information is lost. The corruption (loss of information) is confirmed upon saving the file.
B) You have an add-in that is automatically doing things (DMU) based on values in extensible storage (global or per element). If those values are not present then the automated process is making the wrong choices based on invalid information and potentially corrupting the document.
C) You have an add-in which stores per document settings e.g. sheets to process in batch printing etc. This would represent a limited data loss specific to that add-in.
Thanks for your efforts @xuan_chen
Given these schema conflicts are not new is it worth looking at how such things could be responded to differently by the UI. Rather than having a task dialogue that stops the load could there instead be a balloon tip that notifies upon load that is then logged somewhere and only a modal warning of it before saving/synchronising (when corruption is cemented)?
I think inherently the problem is the problem a classic two into one doesn't go. The lessons are still being learnt one developer at a time regardless as to the recent ElementId issue. The track record unfortunately demonstrates that the level of learning will not improve so perhaps overall it needs thinking about differently (a UI solution).
The following I assume are the kinds of document corruptions that could occur. So users would need to be vaguely aware of what the associated add-in is doing and so gauge how much they can live with it having a bad schema:
A) You have an add-in that stores information per element and the user has stored a lot of information on elements for this schema. If you open a document with all that information but there is already a conflicting schema present then all that information is lost. The corruption (loss of information) is confirmed upon saving the file.
B) You have an add-in that is automatically doing things (DMU) based on values in extensible storage (global or per element). If those values are not present then the automated process is making the wrong choices based on invalid information and potentially corrupting the document.
C) You have an add-in which stores per document settings e.g. sheets to process in batch printing etc. This would represent a limited data loss specific to that add-in.
To follow up on my earlier post two weeks ago, I would like to give an update about the fix we are working on.
The fix is targeting improving product stability and data integrity. We are proactively validating the solution considering the complicated data source and runtime environment. Rome is not built in a day, and I am quoting my earlier thread “We cannot resolve all the problems in one shot considering the RVT format compatibility”.
Nevertheless, we are going to offer a trustable and reliable update, and we are planning on the release of the patch in early September. This is the current plan providing our validation and testing goes well. If that changes, we will provide an update here.
To follow up on my earlier post two weeks ago, I would like to give an update about the fix we are working on.
The fix is targeting improving product stability and data integrity. We are proactively validating the solution considering the complicated data source and runtime environment. Rome is not built in a day, and I am quoting my earlier thread “We cannot resolve all the problems in one shot considering the RVT format compatibility”.
Nevertheless, we are going to offer a trustable and reliable update, and we are planning on the release of the patch in early September. This is the current plan providing our validation and testing goes well. If that changes, we will provide an update here.
Early September? Please make this a priority! You do realize we have to work on actual projects before September?
I got this on a file yesterday and only can load a version I had saved a few hours before the most recent. I removed ALL add-ins (inc. the Autodesk ones) and it didn't help at all.
The only thing I didn't try was to de-install the .1 update since I fear this file (saved in R2024.1) and then being edited in 2024.0 will get messed up.
Yes, I save every 15 minutes. But I don't test every time I do that if that file actually can get loaded.
I'm seriously disappointed in Autodesk on this one. I've used Revit for over a decade and always upgraded immediately. If there was an issue, they released a patch in a timely manner. And the issues weren't huge. But this one is huge (not being able to open a file is huge) and Autodesk are dragging their feet.
Can you at least tell us:
- is there some procedure we should do or avoid to avoid those errors meanwhile?
- are thee any other tricks to open such file?
I contacted support, but don't expect help before Monday (if it even can be helped). So I now have to use the older version and try to re-create what was lost. The worst part is, I don't know if it will happen again. I think for the time being i have to open the saved file right after it was saved to see if it can load.
Early September? Please make this a priority! You do realize we have to work on actual projects before September?
I got this on a file yesterday and only can load a version I had saved a few hours before the most recent. I removed ALL add-ins (inc. the Autodesk ones) and it didn't help at all.
The only thing I didn't try was to de-install the .1 update since I fear this file (saved in R2024.1) and then being edited in 2024.0 will get messed up.
Yes, I save every 15 minutes. But I don't test every time I do that if that file actually can get loaded.
I'm seriously disappointed in Autodesk on this one. I've used Revit for over a decade and always upgraded immediately. If there was an issue, they released a patch in a timely manner. And the issues weren't huge. But this one is huge (not being able to open a file is huge) and Autodesk are dragging their feet.
Can you at least tell us:
- is there some procedure we should do or avoid to avoid those errors meanwhile?
- are thee any other tricks to open such file?
I contacted support, but don't expect help before Monday (if it even can be helped). So I now have to use the older version and try to re-create what was lost. The worst part is, I don't know if it will happen again. I think for the time being i have to open the saved file right after it was saved to see if it can load.
@HVAC-Novice wrote:Early September? Please make this a priority! You do realize we have to work on actual projects before September?
What's stopping you. You can still use earlier versions. Plus, early September is next week.
@HVAC-Novice wrote:Early September? Please make this a priority! You do realize we have to work on actual projects before September?
What's stopping you. You can still use earlier versions. Plus, early September is next week.
That's great news! Keep up the good work. Everyone is excited for the fix.
That's great news! Keep up the good work. Everyone is excited for the fix.
@xuan_chen It is very helpful to know a rough timeframe. Our users are increasingly approaching us with "we cannot open files" or "we cannot get work done in projects which have already started in 2024".
What options do we have to help make this less painful for our thousands of users? It seems as though addins are not even able to remove our own traces because Revit has messed with the schemas. Is there a way that you know of that we can remove the corrupted storage or some steps which users can follow to get the files open?
Sometime in early September still feels like an eternity for companies which cannot do their work on these 2024 projects. Any insight would be helpful.
@xuan_chen It is very helpful to know a rough timeframe. Our users are increasingly approaching us with "we cannot open files" or "we cannot get work done in projects which have already started in 2024".
What options do we have to help make this less painful for our thousands of users? It seems as though addins are not even able to remove our own traces because Revit has messed with the schemas. Is there a way that you know of that we can remove the corrupted storage or some steps which users can follow to get the files open?
Sometime in early September still feels like an eternity for companies which cannot do their work on these 2024 projects. Any insight would be helpful.
I can't use my current project (saved in 2024.1 ) in older versions. And it doesn't' load in R2024.1. Not being able to open project, is a big show-stopper.
And I will believe in "early September" when it is released, and actually enables me to open my project. And I sure hope it is September 2023 and not 2024.....
R2024 was released in April. Making it workable in September would be 5 months. This is a long time for a software with annual versions. Assuming that update actually fixes the issue, this is 5/12 months of a user not knowing if a project that gets saved, actually can get opened again. For R2025 I really have to think of a new policy to wait six months or so before upgrading.
Sorry to sound a bit sour. I can live with some small bug here and there (every software has that, and it hopefully gets patched). Not being able to open a project is more than an inconvenience. Even if I just re-do some hours of work, I don't know if this happens again tomorrow, or next week.
I can't use my current project (saved in 2024.1 ) in older versions. And it doesn't' load in R2024.1. Not being able to open project, is a big show-stopper.
And I will believe in "early September" when it is released, and actually enables me to open my project. And I sure hope it is September 2023 and not 2024.....
R2024 was released in April. Making it workable in September would be 5 months. This is a long time for a software with annual versions. Assuming that update actually fixes the issue, this is 5/12 months of a user not knowing if a project that gets saved, actually can get opened again. For R2025 I really have to think of a new policy to wait six months or so before upgrading.
Sorry to sound a bit sour. I can live with some small bug here and there (every software has that, and it hopefully gets patched). Not being able to open a project is more than an inconvenience. Even if I just re-do some hours of work, I don't know if this happens again tomorrow, or next week.
May or not be related but I've got a project started in 2022 not updated to 2024 that is crashing Revit after a schema warning upon opening. Multiple users have had it happen. Audits by same users is keeping us going for now.
May or not be related but I've got a project started in 2022 not updated to 2024 that is crashing Revit after a schema warning upon opening. Multiple users have had it happen. Audits by same users is keeping us going for now.
One of our add-ins.
One of our add-ins.
Nope.
Nope.
Hope this helps someone. Support was great, and kind of resolved the issue. the end result was they were able to remove the schemas. But this caused the elements that had those schemas (duct fittings in my case) to be removed. So, I had to replace those. but this was much less work than re-doing a lot of work from what I originally was able to open.
But you can't do that yourself and need Autodesk. They reviewed my files (all the backups inc. the ones that I couldn't load and the one I could load and the journal files). Few emails, a phone call, me uploading files . So, this still requires you to work for a day on a different project. But the person who helped me was great.
Obviously there is NO guarantee that they can help you recover your file. YMMV. You also could be stuck just with having to re-build from whatever the last saved file is you are able to open.
The support person said usually those errors happen when people use slight different versions (like 2024 vs 2024.1 and exchange files. This doesn't apply to me, since I'm the only one working on this. He also said upgrading old files and skipping versions could cause this. This also isn't the case for me since it was started in 2024. The error also can happen when you have multiple projects open in the same session. I think this is the bug in 2024, because the schemas shouldn't save to other projects and only be in memory. I'm sure I'm not explaining this well since I don't understand schemas. and if someone could delete any knowledge of schemas from my brain, I would be happy. They are not something a normal user ever needs to know - except now that they cause errors.
Best I can do until a fix is provided is to save frequently (I already had set the reminder to 15 minutes) and open another Revit instance to open the file just saved to see if that actually opens.
Hope this helps someone. Support was great, and kind of resolved the issue. the end result was they were able to remove the schemas. But this caused the elements that had those schemas (duct fittings in my case) to be removed. So, I had to replace those. but this was much less work than re-doing a lot of work from what I originally was able to open.
But you can't do that yourself and need Autodesk. They reviewed my files (all the backups inc. the ones that I couldn't load and the one I could load and the journal files). Few emails, a phone call, me uploading files . So, this still requires you to work for a day on a different project. But the person who helped me was great.
Obviously there is NO guarantee that they can help you recover your file. YMMV. You also could be stuck just with having to re-build from whatever the last saved file is you are able to open.
The support person said usually those errors happen when people use slight different versions (like 2024 vs 2024.1 and exchange files. This doesn't apply to me, since I'm the only one working on this. He also said upgrading old files and skipping versions could cause this. This also isn't the case for me since it was started in 2024. The error also can happen when you have multiple projects open in the same session. I think this is the bug in 2024, because the schemas shouldn't save to other projects and only be in memory. I'm sure I'm not explaining this well since I don't understand schemas. and if someone could delete any knowledge of schemas from my brain, I would be happy. They are not something a normal user ever needs to know - except now that they cause errors.
Best I can do until a fix is provided is to save frequently (I already had set the reminder to 15 minutes) and open another Revit instance to open the file just saved to see if that actually opens.
Sorry for the delayed response, I am from the engineering team and check forum messages regularly.
What options do we have to help make this less painful for our thousands of users?
Before the coming fix releases, I would suggest contacting the support team, based on your model health status, different recovery approaches might be applied.
Sorry for the delayed response, I am from the engineering team and check forum messages regularly.
What options do we have to help make this less painful for our thousands of users?
Before the coming fix releases, I would suggest contacting the support team, based on your model health status, different recovery approaches might be applied.
Some more info from support after they reviewed my journal files:
They seem to think my schema error happened when I had my R2024.1 project open, and upgraded a 2023 file (project or family?) in the same session. Theoretically it shouldn't matter.... and that seems to be the bug. They recommended that when you upgrade an older file, you do that in a new Revit session, and then close that session before open up a file you actually work on.
I should be able to do that since I upgraded everything already. but where it can catch me is if I download a new family for a project and then upgrade that (since all families on the Internet are older versions). So, technically you need to close the project, upgrade the downloaded families, and then re-open a new Revit session. Sometimes I downloads 5 families to find a good starting point.
Some more info from support after they reviewed my journal files:
They seem to think my schema error happened when I had my R2024.1 project open, and upgraded a 2023 file (project or family?) in the same session. Theoretically it shouldn't matter.... and that seems to be the bug. They recommended that when you upgrade an older file, you do that in a new Revit session, and then close that session before open up a file you actually work on.
I should be able to do that since I upgraded everything already. but where it can catch me is if I download a new family for a project and then upgrade that (since all families on the Internet are older versions). So, technically you need to close the project, upgrade the downloaded families, and then re-open a new Revit session. Sometimes I downloads 5 families to find a good starting point.
Hi Everyone,
I wanted to share that today we have released a patch that helps to address this issue with the 2024.1.1 update. You can read more about the update by visiting our blog at https://blogs.autodesk.com/aec/2023/09/06/whats-new-in-revit-2024-1-1/ Its important for everyone using Revit 2024 to update to this version. This update is especially important for worksharing users that all project team members are using this release of Revit or higher. Why? To avoid the possibility of older versions of Revit 2024 reintroducing this problem back to the project teams’ model. Our support article is also being updated with the latest information - https://knowledge.autodesk.com/article/Schema-Conflicts-with-DatasmithRevitExportSettings-and-DataSt...
Hi Everyone,
I wanted to share that today we have released a patch that helps to address this issue with the 2024.1.1 update. You can read more about the update by visiting our blog at https://blogs.autodesk.com/aec/2023/09/06/whats-new-in-revit-2024-1-1/ Its important for everyone using Revit 2024 to update to this version. This update is especially important for worksharing users that all project team members are using this release of Revit or higher. Why? To avoid the possibility of older versions of Revit 2024 reintroducing this problem back to the project teams’ model. Our support article is also being updated with the latest information - https://knowledge.autodesk.com/article/Schema-Conflicts-with-DatasmithRevitExportSettings-and-DataSt...
Thank you very much Xuan Chen and Harlam for the updates here! We look forward to seeing the updated version of the support article and will be doing some testing on our end of this update. We will post our testing results here: https://ideatesoftware.com/blog/important-information-about-revit-2024-1-and-new-schema-errors
Hopefully others will also post their findings. Our testing steps are:
1. Open a new file in 2024 and ensure a Data Storage is in use. This can be done in many ways, but we will load the solution with the schema that previously triggered the condition. We had one customer error that referenced Explorer, for example, so we'll load that first.
2. Next, while that first file is still open, try to upgrade an older file that was previously unsuccesfully upgraded due to this schema error. We have 2 such files from customers, one in 2020 and another in 2022.
Glynnis Patterson
Director - Ideate Software Development
Thank you very much Xuan Chen and Harlam for the updates here! We look forward to seeing the updated version of the support article and will be doing some testing on our end of this update. We will post our testing results here: https://ideatesoftware.com/blog/important-information-about-revit-2024-1-and-new-schema-errors
Hopefully others will also post their findings. Our testing steps are:
1. Open a new file in 2024 and ensure a Data Storage is in use. This can be done in many ways, but we will load the solution with the schema that previously triggered the condition. We had one customer error that referenced Explorer, for example, so we'll load that first.
2. Next, while that first file is still open, try to upgrade an older file that was previously unsuccesfully upgraded due to this schema error. We have 2 such files from customers, one in 2020 and another in 2022.
Glynnis Patterson
Director - Ideate Software Development
Can't find what you're looking for? Ask the community or share your knowledge.