Create a user with dbo privledges in SQL Server Azure?

[MichaelTorbett]

I'm working on a project where I've taken an already existing SQL database in Azure and enabled Enterprise Geodatabase functionality. Following ESRI documentation, my database administrator created a login/user for me to use as the geodatabase administrator. Now what I'm wanting to do is create feature classes and link them to already existing tables in the Geodatabase with relationship classes. However, I am unable to do so because I am not the owner of the existing tables in the database. The existing tables in the database are named in the following format: databasename.dbo.tablename and my feature classes are named databasename.myusername.tablename. I know if I have dbo privledges, then I can create the relationship classes. However, how is this accomplished in Azure? My db admin and I have gone through all of the ESRI and Microsoft docs with no luck. 

We've tried giving 'dbmanager' privileges to my user, but for some reason it's not putting dbo in the new table names. Are we missing something?

Thanks,

Michael

[George_Thompson]

You may need to have the DBO user (db admin in your case) grant your users <username> permission to view the tables. Once you can see them in the ArcGIS client, you should be able to make the relationship class.

This may help: https://pro.arcgis.com/en/pro-app/latest/help/data/geodatabases/manage-sql-server/privileges-sqlserv...

[MichaelTorbett]

Hey George,

Thank you for the information. I can view the tables but it still fails when I try to create a relationship class. Before, I was getting the message "you must be the owner of both tables to create a relationship class." Now that I have db_manager privledges, it's telling me that the tables under the dbo user are not registered with the Geodatabase. It looks like I'll need to have dbo privledges to register those tables with the Geodatabase.

[George_Thompson]

Ah ok. I thought that it might be the case. So, it seems that you have to be the data owner for both the FC and table along with both objects being part of the Enterprise Geodatabase. This is logical since a relationship class is a GDB object.