topic Re: Which Table is Holding Layers Information and Relationship with Actual Tables in Enterprise Geodatabase in Geodatabase Questions

Which Table is Holding Layers Information and Relationship with Actual Tables in Enterprise Geodatabase

BehrouzHosseini — Sun, 12 Dec 2021 10:55:58 GMT

Can you please let me know which table(s) of Enterprise Geodatabase on top of SQL Server contains contains information about layer ID showing on service URL

"layers": [
  {
   "id": 0,
   "name": "Electric.DBO.Open_Point"
  },
  {
   "id": 1,
   "name": "Electric.DBO.Fuse"
  },
  {
   "id": 2,
   "name": "Electric.DBO.Circuit_Breaker"
  },
  {
   "id": 3,
   "name": "Electric.DBO.Recloser"
  },
  {
   "id": 4,
   "name": "Electric.DBO.Switch"
  },
   ...‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

and how they are connected (has reationship) with physical tables in Geodatabase?

Re: Which Table is Holding Layers Information and Relationship with Actual Tables in Enterprise Geodatabase

KevinDunlop — Wed, 11 Oct 2017 18:12:23 GMT

You will need to look at the MXD you used to publish the service. The layers in the MXD should correspond to the layers in the service. Then it is a matter of looking at source tab of each layer to determine it's table.

Remember also that if your data versioned then there is 3 tables and not 1 you will need to look at. There is the base table, then A & D tables (ex A512 and D512 would be for the same layer).

Re: Which Table is Holding Layers Information and Relationship with Actual Tables in Enterprise Geodatabase

VinceAngelo — Wed, 11 Oct 2017 19:24:04 GMT

Note: Previously posted in GIS StackExchange, but put on hold for being unclear.

- V

Re: Which Table is Holding Layers Information and Relationship with Actual Tables in Enterprise Geodatabase

VinceAngelo — Thu, 12 Oct 2017 16:47:03 GMT

You seem to be conflating two different abstraction layers. There is a set of database tables which maintains versioned geodatabase metadata, which is documented online, but this has little to do with the layers in a Server map service.

Worse yet, even though the default layer name in a map document is based on the data source table, it is not safe to assume that the actual source is the name in the layer list (it could have been changed, or cross-threaded, by mistake or otherwise). Best practice is to save a snapshot of the state of the MXD at the time of publishing, so you can look up the actual source, if needed. Note that the map document is a file, not a database, so while the document has a number of properties, including a layer list, and the layers have properties, including a data source, the data is not in any database, per se, and only accessible via GUI or the arcpy.mapping module through Python.

-V