Not able to delete Extensible Storage schema

[snajjar]

I'm trying to put together a command to erase Extensible Storage (ES) data and the corresponding Schemas for our addin in case if unwanted by the users or corrupt. I had no luck so far. 

After the ES data has been written to the file it won't go away. I am being able to delete the DataStorage elements with no troubles, but the schemas keep popping up after erasing them.

The procedure I'm trying is:

1. Open the Revit file with the saved ES data.
2. Delete all the DataStorage elements holding the data.
3. Save and close Revit, reopen the file again.
4. Erase all schemas created by our addin.
5. Save and close Revit to make sure I clear the schemas in memory.
6. Start Revit again.
7. Use the Schema.ListSchemas() function with no documents open to make sure our custom schemas are not loaded, this clears out.
8. Open the file and use the Schema.ListSchemas() function, now all the schemas that I have erased previously reappear after opening the file!

I'm using the same procedure found in the "ExtensibleStorageUtility" code example in the Revit SDK in a macro (code below).

One observation I have that if I close Revit without saving after step 4 I get no warning to save the file as if no changes happened to the file, although I'm doing the erase inside a transaction.

This article has some info on ES and Schema behaviors that I tried to utilize but didn't work.

Below is the macro function I'm using:

		public void DeleteSchemas() {
			
			var uiDoc = this.ActiveUIDocument;
			var document = uiDoc.Document;
			
			var message = "";				
			IList<Schema> schemas = Schema.ListSchemas();
			int deleted = 0;
			int count = schemas.Count;
			
			using(Transaction tErase = new Transaction(document, "Erase EStorage")){
				
				tErase.Start();
				
				foreach (Schema schema in schemas.Where(s=> s.VendorId == "MYAD"))
				{
					//Note-this will delete storage of this schema in *all* open documents.
					try{
						document.EraseSchemaAndAllEntities(schema);
						Schema.EraseSchemaAndAllEntities(schema, true);
						deleted++;
					} catch {
						
					}
				}
				tErase.Commit();
			}
			
			message =string.Format( "{0} storage elements out of {1} were deleted.", deleted.ToString(), count.ToString());
			
			TaskDialog.Show("ExtensibleStorageUtility", message);
		}

Any light on this would be much appreciated.

Thanks!

[jeremy_tammik]

Yes, that is the issue. However:

> the process must be to erase the current schema and provide an updated replacement schema

No, no, no!

You cannot replace a schema. Ever. Every single schema is for eternity.

I can only repeat what has already been stated above and elsewhere:

You cannot replace a schema. Ever. Every single schema is for eternity.

You can create a new schema, equipped with a new GUID. If you would like to create a million different schemata and manage the updating process from one to another, please go ahead and do so.

However: 

You cannot replace a schema. 

[JeffStuy]

Which brings me back to the original reason for this thread.  This method:  Document.EraseSchemaAndAllEntities, per its description (Erases Schema and all its Entities from the document), is supposed to eliminate the Schema, data, etc. which would allow a replacement schema, data, etc. (with a new GUID of course) be installed. 

But this method fails to work. 

And, the work-arounds noted above, even if they do work, are too onerous to use an an alternative.

If this method were to work correctly, then I would not have "a million different schema" hanging around in the model and it would be possible to update the Schema and Data.

To my prior point, if this method will not work as indicated, in all versions of at least starting with 2021, then ExtensibleStorage has little value.  I really do not see much benefit of placing an immutable and un-erasable object into any model.  And, I would never want to leave objects like this behind if someone wished to remove my product.

[jeremy_tammik]

Yes. Good. I agree. The statement "with a new GUID of course" is the key. In that case, the new schema is a new schema, not a replacement. It is new. So, I now completely agree with your statement.

Afaik, the development team are aware of issues erasing the schema in certain versions under certain circumstances and are working on fixing that.

Meanwhile, as suggested in the other discussion I just pointed out, you can remove all traces of your schema and its data simply by deleting all associated extensible storage data entities. Just don't worry about the schema at all.

How does that sound?

[JeffStuy]

As I recall, I tried erasing the data entity and that also did not work.  The entity was removed but the schema definition remained.  And, since the schema definition includes the GUID, I would need a new GUID each time.  Which I also tried but it became very difficult to keep track of which schema definition was the current definition.  I added a timestamp but this just became a burden.  And, the basic problem remained - leaving objects in the model that do not belong there.

Unless this has changed?

[jeremy_tammik]

Yes. Every schema modification requires a new GUID. 

I would suggest defining a single schema that satisfies your needs once and for all. Then, you can simply replace the data if something changes. Why would you need to change the schema all the time?

[JeffStuy]

Two items.  

1. not a case of changing the schema "all of the time" but it will need to change.  In my case, for example, when a user gets added or removed.  Or, when a data field gets added or removed.

2. even if it never changed, I must be able to remove the schema if the product is removed.  That is just proper.

Note that the extensible storage system is the only method of creating a data store that is always available to everyone no matter where they are physically located that is also completely hidden from users.  If I cannot completely remove the schema, as the method indicates, I cannot use the extensible storage system.

[jeremy_tammik]

Sounds like serious misunderstanding.

What you describe sounds 100% like changing DATA.

Not changing the schema.

For instance, your schema could be something like:

  user: string
  data: string

So, you can change your user and data to your heart's content and yet never, ever, touch the schema.

Does that help?

[JeffStuy]

Maybe and no.  I will need to test.  this may allow me to modify the data and add / delete information.  But this still does not resolve the need to remove the schema from the model.

[ivo.lafeber]

We also do not need to update a schema all the time, but when a schema is updatet because of a software change. the schema needs to be updatet in all the models which use that schema. 

It would be nice to add that feature in the future. 

[jeremy_tammik]

Dear Ivo,

Sorry, but this is getting ridiculous.

You cannot update an existing schema. 

Not often, not seldom, not once, not ever.

If you publish a schema, you have published it forever. Every extensible storage schema is immutable.

If you discover that you need a different schema, you cannot change the existing one.

If you really run into such a need, which I would recommend avoiding at all costs, you can do as follows:

• Implement a NEW schema
• From now on, use the NEW schema exclusively for storing data
• Implement code to detect instances of the old schema and convert them to NEW schema entities

These principles were highlighted right from the inception of the extensible storage introduction. Please read the initial posts on the topic:

• https://thebuildingcoder.typepad.com/blog/about-the-author.html#5.23

Especially, please pay heed to this note from the year 2013, just over ten years ago:

• https://thebuildingcoder.typepad.com/blog/2013/08/deleting-and-updating-extensible-storage-schema.ht...

Thank you.

I pray I never again hear the word 'update' in this context. 

Best regards

Jeremy

[jeremy_tammik]

Here is another nice discussion of how to handle this, from 2018:

• Extensible Storage – Versioning Best Practices
  https://thebuildingcoder.typepad.com/blog/2018/06/exte...

[jeremy_tammik]

Hope the issue is resolved now in Revit 2024.2:

• https://thebuildingcoder.typepad.com/blog/2023/11/revit-20242-update-with-uda-preview.html#3

[Ning_Zhou]

seems this issue is not yet fixed in Revit 2024.2, isn't it?

[jeremy_tammik]

Yes, it is, cf. the link above. I repeat it here for you as well:

https://thebuildingcoder.typepad.com/blog/2023/11/revit-20242-update-with-uda-preview.html#3

[swfaust]

Sorry but this is still not working for me in 2024.2.  I have a single document open (only document opened since Revit started) that has a schema in it.  I run my super simple command that basically checks if the schema exists; if not it tells you it doesn't exist but if it does it runs 'doc.EraseSchemaAndAllEntities' then tells you it worked.  I run this and it says it worked (so that it erased it).  I can then go to purge and it shows the schema as an option to purge so I do.  I then use RevitLookup to list the schemas and it's still there.  I can run this process over and over again (erase, purge, check, erase, purge, check, etc.) and it never disappears.  I have also tried restarting Revit after the purge but same result, when I open Revit back up and open the document the schema is still there.

For completeness, here is my code to clear it out:

        public Result Execute(ExternalCommandData commandData, ref string message, ElementSet elements)
        {
            var doc = commandData.Application.ActiveUIDocument.Document;
            var id = new Guid(Constants.SchemaId);
            var schema = Schema.Lookup(id);

            if (schema == null)
            {
                TaskDialog.Show("Schema Not Found", "The old schema was not found, no update is necessary.");
                return Result.Cancelled;
            }

            using (var t = new Transaction(doc, @"Repair Extensible Storage"))
            {
                t.Start();

                doc.EraseSchemaAndAllEntities(schema);

                t.Commit();
            }

            TaskDialog.Show("Success", "The schema has been updated");

            return Result.Succeeded;
        }

Sorry but pretty sure it's not fixed.  Has anyone else found a way to do this?

[renencon]

Same issue here with latest 2024.2 relase. Exactly the same procedure but the schema reappears even after a purge, save, restart revit and reopen file.

In 2025 however looks like it has been fixed, although i need to do more testing.

Maybe we should wait for Autodesk to release an update for 2024 to address this issue.

[varibrus_ds]

Good afternoon

Tell me, when will the new Revit 2024 update (patch) be released?
Since in the latest patch (2024.2.1 Update released on April 16, 2024) the problem with scheme conflicts is not fixed!

When you open a working model, and the linked model contains a schema, the working model also displays a schema conflict notification.

Automatic checks such as Model Checker do not work due to a schema conflict (Revit session closes).

[jeremy_tammik]

The nomination for the Revit 2024.2 update was cancelled, I'm afraid. I asked the development team for the current plans for REVIT-203545 [Unable to delete extensible storage].

[jeremy_tammik]

Good news. They are working on it. There may be separate Revit 2024 updates for the extensible storage schema enhancements and other issues. As always: no promises, no dates, no guarantees.

[hemmesMW2F3]

I have this same issue in Revit 2024. The new Document.EraseSchemaAndAllEntities does not work.
I find it troubling that the dev team came back with a blunt "Do it yourself manually with Purge Unused" (paraphrasing).