[Solved] Safe to delete rows in dbo.umbracoServer?

[heady plume]

I am trying to import a bacpac that is a dump of a production environment.

Azure Data Studio gives me an error:

Import bacpac: Data plan execution failed with message One or more errors occurred. (One or more errors occurred. (One or more errors occurred. (Violation of PRIMARY KEY constraint 'PK_umbracoServer'. Cannot insert duplicate key in object 'dbo.umbracoServer'. The duplicate key value is (1).
The statement has been terminated.)))
One or more errors occurred. (One or more errors occurred. (One or more errors occurred. (Violation of PRIMARY KEY constraint 'PK_umbracoServer'. Cannot insert duplicate key in object 'dbo.umbracoServer'. The duplicate key value is (1).
The statement has been terminated.)))

Is it safe to "clear" this table of data to avoid this duplicate key before doing the export/import?

[frigid locust]

Yes. From my observations, this table seems like it should be used for multi-instance deployments (i.e. "load balanced Umbraco installations" according to the docs) but I've never seen it populated with anything useful. Looking at our production databases, it contains developer workstation names and other random stuff.

[austere sandal]

Which is extremely useful - in load balanced scenarios. 🙂

@heady plume yes, these are a list of the instance that we've detected running on the same database, in a load balanced scenario that helps Umbraco determining where to build caches etc. But if you delete them, they will just be repopulated when you restart the app, so all good.

[heady plume]

Thanks, good to know

[frigid locust]

What I meant is that we haven't actually seen it working on load-balanced installations in production. The table is always full of random stuff, but the multi-instanceness works anyway. I think we also had to change the "app ID" resolver in Umbraco to allow same-machine multi-installations, as the machine name was used as the app ID... but this can have been back in '8

[austere sandal]

The only way a machine name ends up in there if the machine connects to the database, or if you deploy that table verbatim between environments.

But it also depends on your load balance config as to whether this table is actually being used, hard to tell as there are many variables in play.