Constraint executing before calculation error

[OliverSandoval_p]

Hello,

We need to have a calculation and constrain triggered on insert. The constraint evaluates whether the field(that has been calculated with a calculation rule) is a certain value. 

This works in a file geodatabase, but not an sql geodatabase.

So in the sql database the constraint is evaluated first before the calculation has taken place, so you can never insert a new record. Is there a possible explanation for this, or is there some documentation that I'm missing that I can be directed to? Thank you for your time! 

[HusseinNasser2]

Constraint rules are always evaluated after Immediate calculation rules in the execution order. 

I'd like to request few details to understand the context, Is the SQL Geodatabase client server direct connect Or published through a service? And What is the versioning model and DBMS? Also the Pro used and Enterprise Versions. 

While you get those try the following, turn off "Exclude from application evaluation"  on the constraint rules and calculation rules. 

[OliverSandoval_p]

Hi Hussein,

I tried exclude from application and it did not work, here are the details you asked for per my supervisor. 

Traditional Versioning model

Enterprise 10.8.1 

Microsoft SQL Server 2019

Windows Server 2019

Pro 2.8.2

We are currently testing direct connect from Pro to Sql server but the end goal is to update to 10.9.1 by the end of the year and utilize the attribute rules in enterprise 10.9.1 with sql server as registered datastore and the feature service referencing a traditional edit version. The attribute rules are for a data collecting workflow. 

[OliverSandoval_p · Accepted solution]

There was a tech support case that I opened, it took about 1.5 months, but we were able to narrow it down to the way the sql database was created. The attribute rules were tested on sde files that were copied and pasted, feature table in the same database worked fine with the attribute rules if it was created, not copied. Before this I was able to create an alternate script that worked fine either way.