Is branch versioning in Pro compatible with SQLExpress 2012?

[CharlesBailey]

I am working with an SDE database created in Arcmap 10.6.x, which is in a SQLExpress 2012 instance. I am able to set the geodatabase properties to branch versioning in ArcPro 2.3. I have tried both importing data from AGOL and creating a new feature class in the database,  and in both cases the properties of the dataset indicate that the data is branch versioned also. But when trying to share the branch versioned data I receive an error related to the dataset owner. Although I connected and created the data as the 'sa' user, Pro is convinced that dbo is the dataset owner - this even though I enabled the sde schema when creating the database. I have gone to the SQL side and created users that have ownership privileges and also a 'dbo' login, but when those are used the Version Management option is not enabled in the Share tool dialog. I'm no SQL expert for sure but starting to think it might be a compatibility issue - the version of Pro required for branch versioning is not compatible with SQL2012 and fails to create the enterprise database (which is why arcmap 10.6 was used). Can anyone confirm this? If so would there be any other issues with backward compatibility if we install SQL 2016 on our GIS server, since our primary non-spatial database is running on 2012? Thanks, cob

[KoryKramer]

Geodatabase‌

[AlexanderThurstlic]

Hi Charles,

This is a known limitation when working with branch versioned datasets in SQL Server.  The Version Management capability will not be available if the datasets that you have registered as versioned using the Branch versioning type are owned by dbo.

When working with SQL Server databases, version management cannot be enabled if the data being shared is owned by a dbo user. It is recommended that dbo users do not own any datasets in your enterprise geodatabase.

https://pro.arcgis.com/en/pro-app/help/sharing/analyzer-error-messages/00277-version-management-is-e...

Additionally, the 'sa' user is the server administrator and will be part of the sysadmin fixed server role in the SQL Server instance.  All members of this role are considered dbo users. In the geodatabase, that means all data owned by server administrators are owned by dbo and stored in a schema named dbo, even if you set up with SDE as the geodatabase administrator and owner of the geodatabase repository.

http://desktop.arcgis.com/en/arcmap/latest/manage-data/gdbs-in-sql-server/geodatabase-administrator-...

[CharlesBailey]

I saw that; there are also several posts that indicate it does work. But the question is how do I get data into the database that isn’t dbo owned? I’ve tried several methods to no avail. Again the db is enabled for sde scheme when created. Anything I bring in is db.DBO.data it seems. Thanks for your response.

cob

[AlexanderThurstlic]

Hi Charles, 

Users who create data must have a default schema in SQL Server with the same name as their database user name. For example, if you have a user called 'GIS' mapped to the database, you will need to ensure in SQL Server that the user's default schema name is also 'GIS'.   Also, that user cannot be part of the 'sysadmin' fixed server role, since any user in that role will have the 'dbo' schema by default.

[CharlesBailey]

Thank you Alexander. How do I set the schema for data that I bring into the database? I’ve logged in as sde and imported data and it’s still dbo. In the table in ssms the only user listed is sde and it gets permissions granted by dbo. I’m just testing so this could be any data. Thanks, cob

[AlexanderThurstlic]

Hi Charles,

In SQL Server Management Studio, connect to the instance hosting the geodatabase:

Security folder > Logins > double-click on 'sde' login or other data creator logins > User Mapping

Does the Default Schema match the User name?  

[CharlesBailey]

Yes, for the two test databases both are sde. Thanks, cob

[AlexanderThurstlic]

Security folder > Logins > double-click on 'sde' login or other data creator logins > 'Server Roles'

Is the sde login a member of the sysadmin server role?

[CharlesBailey]

No, it’s only public.

Thanks, cob