Following the question posted here , I would like to propose the addition of a new optional parameter in the Evaluate Rules gp tool to specify the version name directly, instead of embedding it within the workspace connection string (https://...my-feature-server;version=my-version-name). This adjustment would streamline workflows, improve user experience, and allow for better handling of complex versioning scenarios in enterprise geodatabases.
If this version name parameter is provided, it would be automatically appended to the workspace connection string, making the process more seamless and less error-prone. If not provided (None) the tool will be executed on the sde.Deafult version.
Why this is Necessary?
Currently, when using the Evaluate Rules tool with a versioned enterprise geodatabase, the version name must be included in the workspace connection string in a specific format. This can be problematic, especially when the version name contains special characters such as slashes (/). The tool fails when such characters are present- raising an error regarding the workspace.
How This Would Enhance the Tool?
By adding a dedicated version name parameter to the Evaluate Rules tool, users would be able to specify the version directly without the need to modify the workspace string.
This enhancement would:
- Simplify the Workflow: Users can specify the version independently, without needing to handle special characters or reformat workspace paths.
- Improve Error Handling: This change would prevent common errors related to improperly formatted version names or the need to escape characters.
- Efficiency: Automating the inclusion of version names through a dedicated parameter would reduce the manual steps involved, especially for large datasets or automated workflows.
- Enhance Versioning Flexibility: Users would have better control over their geodatabase versions, enabling more dynamic and adaptable workflows, particularly in multi-versioned environments.
- Future Proof: With the increasing complexity of version naming conventions (e.g., incorporating date-time or slash-based hierarchies), this change would make it easier to scale and support these new conventions.
