Populate Workspace Properties in Generate Schema Report output for all input dataset types

[JBeasley]

The Generate Schema Report tool can be run on workspaces, feature datasets, feature layers, and tables, but, when you input anything other than a workspace (.sde, .gdb), the Workspace Properties are blank or incomplete. At a minimum, I would expect the Path (or catalogPath for JSON outputs) variable to be populated with the full path of the input- which could be the REST URL for feature layers. 

[VenkataKondepati]

Thanks for pointing this out — I’ve noticed the same behavior with the Generate Schema Report tool. When running it on datasets or services instead of a workspace, having the Workspace Properties section come back incomplete makes it harder to trace the source of the schema.

At the very least, populating the Path / catalogPath with the full input location (e.g., .sde connection file path, .gdb, or REST URL for feature layers) would provide needed context in the JSON outputs. This would make the reports far more useful for documentation, auditing, and automation.

+1 to enhancing this tool so we always get clear source information regardless of input type.

Regards,

Venkat

[SSWoodward]

Thanks for the Idea.  I'm chatting with the team about it, now.  

@VenkataKondepati, @JBeasley,  you both mentioned that at the very least you'd want the catalog path.  What's on the other side of the scale here? What additional information are you after that you'd like to see included in the workspace section of the report?

[VenkataKondepati]

Hi @SSWoodward,

Thanks for looping me in. Yes, the catalog path would be the minimum baseline — it gives us clear traceability back to the source, whether that’s an .sde connection, a .gdb, or a REST URL.

On the “more complete” side, a few things that would make the workspace section much more useful for admins and automation:

• Connection type (file gdb, enterprise gdb, service URL, etc.)

• Connection properties (database/server name, service name, user/schema) – nothing sensitive, just enough for context

• Version info (workspace release, database type/version)

• Spatial reference defaults if known

• Data source metadata like owner, last modified, or size if available

Having this richer context alongside the schema details would make the report not just a structure dump, but a true audit tool for documenting and troubleshooting environments.

Regards,
Venkat

[SSWoodward]

Thanks for this extra context @VenkataKondepati,  its very helpful.

For the purposes of this ideas status, we'll keep it focused on a request to get the workspace info included in the workspace properties when reporting on a single class or feature service layer. I'll make sure to keep these additional points of interest in mind as we continue to develop the report. 

We also have a open forum for schema report feedback that might be interesting to you. I've linked it below.

Schema Report Feedback