<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>idea Evaluate Rules GP Tool: Adding Version Name Parameter in Attribute Rules Ideas</title>
    <link>https://community.esri.com/t5/attribute-rules-ideas/evaluate-rules-gp-tool-adding-version-name/idi-p/1659537</link>
    <description>&lt;P&gt;Following the question posted &lt;A href="https://...my-feature-server;version=my-version-name" target="_self"&gt;here&lt;/A&gt; , I would like to propose the addition of a new &lt;STRONG&gt;optional&lt;/STRONG&gt;&amp;nbsp; parameter in the Evaluate Rules gp tool to specify the version name directly, instead of embedding it within the workspace connection string (&lt;FONT color="#3366FF"&gt;https://...my-feature-server&lt;/FONT&gt;&lt;STRONG&gt;&lt;FONT color="#FF0000"&gt;;version=&lt;/FONT&gt;&lt;EM&gt;&lt;FONT color="#FF6600"&gt;my-version-name&lt;/FONT&gt;&lt;/EM&gt;&lt;/STRONG&gt;). This adjustment would streamline workflows, improve user experience, and allow for better handling of complex versioning scenarios in enterprise geodatabases.&lt;BR /&gt;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.&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;Why this is Necessary?&lt;BR /&gt;&lt;/STRONG&gt;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.&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;How This Would Enhance the Tool?&lt;BR /&gt;&lt;/STRONG&gt;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.&lt;BR /&gt;This enhancement would:&lt;/P&gt;&lt;OL class="lia-list-style-type-lower-alpha"&gt;&lt;LI&gt;Simplify the Workflow: Users can specify the version independently, without needing to handle special characters or reformat workspace paths.&lt;/LI&gt;&lt;LI&gt;Improve Error Handling: This change would prevent common errors related to improperly formatted version names or the need to escape characters.&lt;/LI&gt;&lt;LI&gt;Efficiency: Automating the inclusion of version names through a dedicated parameter would reduce the manual steps involved, especially for large datasets or automated workflows.&lt;/LI&gt;&lt;LI&gt;Enhance Versioning Flexibility: Users would have better control over their geodatabase versions, enabling more dynamic and adaptable workflows, particularly in multi-versioned environments.&lt;/LI&gt;&lt;LI&gt;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.&lt;/LI&gt;&lt;/OL&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Wed, 22 Oct 2025 08:02:52 GMT</pubDate>
    <dc:creator>Ofir_Mazor</dc:creator>
    <dc:date>2025-10-22T08:02:52Z</dc:date>
    <item>
      <title>Evaluate Rules GP Tool: Adding Version Name Parameter</title>
      <link>https://community.esri.com/t5/attribute-rules-ideas/evaluate-rules-gp-tool-adding-version-name/idi-p/1659537</link>
      <description>&lt;P&gt;Following the question posted &lt;A href="https://...my-feature-server;version=my-version-name" target="_self"&gt;here&lt;/A&gt; , I would like to propose the addition of a new &lt;STRONG&gt;optional&lt;/STRONG&gt;&amp;nbsp; parameter in the Evaluate Rules gp tool to specify the version name directly, instead of embedding it within the workspace connection string (&lt;FONT color="#3366FF"&gt;https://...my-feature-server&lt;/FONT&gt;&lt;STRONG&gt;&lt;FONT color="#FF0000"&gt;;version=&lt;/FONT&gt;&lt;EM&gt;&lt;FONT color="#FF6600"&gt;my-version-name&lt;/FONT&gt;&lt;/EM&gt;&lt;/STRONG&gt;). This adjustment would streamline workflows, improve user experience, and allow for better handling of complex versioning scenarios in enterprise geodatabases.&lt;BR /&gt;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.&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;Why this is Necessary?&lt;BR /&gt;&lt;/STRONG&gt;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.&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;How This Would Enhance the Tool?&lt;BR /&gt;&lt;/STRONG&gt;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.&lt;BR /&gt;This enhancement would:&lt;/P&gt;&lt;OL class="lia-list-style-type-lower-alpha"&gt;&lt;LI&gt;Simplify the Workflow: Users can specify the version independently, without needing to handle special characters or reformat workspace paths.&lt;/LI&gt;&lt;LI&gt;Improve Error Handling: This change would prevent common errors related to improperly formatted version names or the need to escape characters.&lt;/LI&gt;&lt;LI&gt;Efficiency: Automating the inclusion of version names through a dedicated parameter would reduce the manual steps involved, especially for large datasets or automated workflows.&lt;/LI&gt;&lt;LI&gt;Enhance Versioning Flexibility: Users would have better control over their geodatabase versions, enabling more dynamic and adaptable workflows, particularly in multi-versioned environments.&lt;/LI&gt;&lt;LI&gt;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.&lt;/LI&gt;&lt;/OL&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Wed, 22 Oct 2025 08:02:52 GMT</pubDate>
      <guid>https://community.esri.com/t5/attribute-rules-ideas/evaluate-rules-gp-tool-adding-version-name/idi-p/1659537</guid>
      <dc:creator>Ofir_Mazor</dc:creator>
      <dc:date>2025-10-22T08:02:52Z</dc:date>
    </item>
  </channel>
</rss>

