topic Re: Relationships to non-geodatabase enabled db/tables in Geodatabase Questions

Relationships to non-geodatabase enabled db/tables

WarrenMedernach — Fri, 14 Oct 2016 18:49:19 GMT

Can non 'geodatabase enabled' db tables be related to a different geodatabase where the spatial features reside?

IOW, I have an existing/established database with applications built around this db (Database A), and I would like to now relate this data to some spatial objects in another geodatabase (Database B). I'm not sure if I want to 'geodatabase enable' Database A and would prefer to create the spatial objects in Database B and establish the relate back to Database A.

Is this a supported workflow? Suggestions/ideas greatly appreciated.

Warren

Re: Relationships to non-geodatabase enabled db/tables

JakeSkinner — Fri, 14 Oct 2016 18:58:28 GMT

Hi Warren,

You could create the relate in the MXD by right-clicking on the feature class > Joins and Relates > Relates. This relate will only exist in the MXD. You will not be able to create a relationship class from the feature class to the database table. Both the feature class and table would need to exist in the same geodatabase in order to create a relationship class.

Re: Relationships to non-geodatabase enabled db/tables

WarrenMedernach — Fri, 14 Oct 2016 19:21:14 GMT

Thanks for the quick response Jake. That's not what I was hoping to here, but at least I know it's not supported. In the end, I would like to be publishing this data so relationship classes will be required.

I'm curious then, what is the workflow for large organizations when they want to consume existing attribute data tables that reside in corporate databases where there is no way the database would be allowed to be 'geodb enabled'? I can't be the only one who has wanted to attempt this sort of configuration? Am I missing something, or some other way to do this?

Warren

Re: Relationships to non-geodatabase enabled db/tables

JakeSkinner — Fri, 14 Oct 2016 19:25:33 GMT

I would recommend having a scheduled export/replication from the database to the geodatabase.

Re: Relationships to non-geodatabase enabled db/tables

WarrenMedernach — Fri, 14 Oct 2016 19:45:24 GMT

Aaaah, that makes sense... probably a more secure/robust method as well.

Thanks again for the quick responses Jake!

Re: Relationships to non-geodatabase enabled db/tables

RandyKreuziger — Fri, 14 Oct 2016 21:44:15 GMT

Why not create a database view in the geodatabase joining data from the geometry field(and any other attributes from the feature class) to attributes from a table in the non-spatial database? We do this all the time. It does require guest permissions on the data in the non-spatial database.

Having said that, we also have scripts scheduled weekly to create standalone feature classes from non-spatial databases. It all depends on the use and the needs of the GIS users.

Re: Relationships to non-geodatabase enabled db/tables

User35489 — Sun, 16 Oct 2016 06:40:34 GMT

Hi,

Similar scenario discussed in below thread. Have a look at it.

https://community.esri.com/thread/171929

Regards

Re: Relationships to non-geodatabase enabled db/tables

WarrenMedernach — Mon, 17 Oct 2016 17:42:01 GMT

Thanks for the additional info Randy, Abdullah.

I believe my scenario is a little different, and should be even simpler. I simply want to create a relationship class between a feature class in my geodatabase, and a 'data table' residing in a different database. This is a 1:M relationship so doing a straight join is not what is required.

I'm not really sure what I'm doing wrong, but I have NEVER had any success getting ArcGIS to recognize SQL Server Views for a relationship class. It doesn't seem to matter if it is a regular view, or materialized/indexed view, the 'Register with Geodatabase' is always grayed out.

I will be attempting the replication method here shortly.