# Validation Rule triggering on local server but not on cloud server - Right side value unexpected

**URL:** <https://community.dhis2.org/t/validation-rule-triggering-on-local-server-but-not-on-cloud-server-right-side-value-unexpected/77820>\
**Category:** Implementation - Implémentation\
**Tags:** aggregate, data-quality, validation-rules\
**Created:** [30 October 2026 09:11 UTC](https://community.dhis2.org/t/validation-rule-triggering-on-local-server-but-not-on-cloud-server-right-side-value-unexpected/77820 "2026-10-30T09:11:14Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![AllanLusui](https://dhis2.b-cdn.net/user_avatar/community.dhis2.org/allanlusui/32/48813_2.png) [@AllanLusui](https://community.dhis2.org/u/AllanLusui)\
**Post date:** [30 October 2026 09:11 UTC](https://community.dhis2.org/t/validation-rule-triggering-on-local-server-but-not-on-cloud-server-right-side-value-unexpected/77820/1 "2026-10-30T09:11:15Z")

</div>

**Context:** I have a validation rule configured to check that:

_Total deliveries (left side) \<= Total births (right side)_

In the data entry form; left side= 152, right side =160

**In the validation rule message I’m getting the below message**  
_Total deliveries (Cesarean sections, Instrumental vaginal deliveries, Spontaneous vaginal delivery, Unknown mode of delivery) by type must be LESS THAN OR EQUAL TO total births (live birth and stillbirths)_

_Total deliveries: Cesarean sections (General & spinal anesthesia, General anesthesia, Spinal anesthesia), Instrumental vaginal deliveries (Forceps, Vacuum extraction, Embryotomy), Spontaneous vaginal delivery, Unknown mode of delivery (152) \<= Total births: Live births, Stillbirths (FHR absent on admission, FHR present on admission, Unknown FHR) (151)_

**Left side expression (152):** `#{fGvQmkETuK8} + #{L0TH6xonmn4} + #{TinmnNVgr3e} + #{NAwkAyppP7I} + #{Qho3gexDZdr} + #{DBYo09mhJWy} + #{tqZ8Cx6faf9} + #{avhJOYxTW29} + #{kKBl5oeVNPy}`

**Right side expression (151):** `#{KahiDLRSSEu} + #{SlrRESnRo1u} + #{SpxKrY1dAR5} + #{QO212R7y7QW}`

**Issue:**

- On our **cloud server** : no validation errors are triggered despite values exactly matching what we have in the local.(data sync done and is successful)
- On our **local server** : a violation is reported, with the left side computing to **152** and the right side computing to **151** - which is unexpected since the value in the form is 160. **We are basically wondering where did the 151 come from given we can’t see it anywhere in the system?**

**Questions:**

1. Could differences in **Missing value strategy** configuration between the two servers explain this behaviour?
2. Could there be **metadata or data differences** between the two environments causing this discrepancy?
3. Has anyone experienced validation rule results differing between a local and cloud DHIS2 instance for the same dataset and period?

**DHIS2 version:** 2.42.6  
**Data Entry App Version:** 102.1.6  
**Steps already taken:**

- Verified the validation rule expression configuration
- Compared left and right side totals manually
- Checked the Local DataBase for soft deleted Values - None exist

Thanks!  
Allan

---

<div class="post-metadata">

**Author:** ![fidelelukeka](https://dhis2.b-cdn.net/user_avatar/community.dhis2.org/fidelelukeka/32/47692_2.png) [@fidelelukeka](https://community.dhis2.org/u/fidelelukeka)\
**Post date:** [3 November 2026 09:01 UTC](https://community.dhis2.org/t/validation-rule-triggering-on-local-server-but-not-on-cloud-server-right-side-value-unexpected/77820/2 "2026-11-03T09:01:55Z")

</div>

Hi Allan,

Thanks for sharing this detailed issue. I think there are a few things worth investigating before concluding that this is a synchronization or validation engine issue.

Based on your example, the expected calculation is:

- Total deliveries = 152

- Total births = 160

- Expected result: 152 \<= 160 (validation should pass).

However, the validation engine reports 151 as the right-side value. This suggests that the values being evaluated by the validation rule may not be exactly the same as those displayed in the data entry form.

I would suggest investigating the following:

**1. Check the individual data element values**

In Data Quality → Validation Rule Analysis, run the validation rule for the affected organisation unit and period, then open the violation details (Show details).

Check the individual values returned for these four data elements:

- KahiDLRSSEu

- SlrRESnRo1u

- SpxKrY1dAR5

- QO212R7y7QW

This should help identify which element contributes to the unexpected total of 151.

**2. Verify Category Option Combos (COCs)**

Since this is an aggregate dataset, I would pay particular attention to the category option combinations.

Is the value of 160 displayed in the data entry form a consolidated total across several category option combinations, or does it correspond to the exact combinations referenced by the validation rule?

It would be useful to verify that the rule evaluates the intended disaggregations.

**3. Compare Attribute Option Combos (AOCs)**

Please also confirm that both environments are evaluating the same Attribute Option Combo, organisation unit and period.

Even when data synchronization is successful, it is worth verifying that the underlying data values and metadata are identical in both environments.

**4. Check Missing Value Strategy**

I would compare the missing value strategies configured on both sides of the validation rule.

However, I would not consider this the primary explanation for the difference between 160 and 151. Missing value strategies determine how missing operands are handled; they do not normally explain why an existing value is evaluated differently.

**5. Compare the actual data values through the API**

As an additional diagnostic step, you could retrieve the four data elements’ values from both servers using the DHIS2 Data Value API, making sure to use the same period, organisation unit, category option combo and attribute option combo.

This would help establish whether the discrepancy originates from the stored data or from the validation evaluation process.

**One question that could help narrow this down:**

When you inspect the four right-side data elements individually, do their values add up to 151 on the local server, or do they add up to 160 as expected?

If the individual values add up to 160 but the validation engine still reports 151, I would investigate a possible issue in the validation evaluation context or engine, and consider preparing a reproducible test case for the DHIS2 core team.

I hope this helps narrow down the issue. Looking forward to hearing what you find!

---

<div class="post-metadata">

**Author:** ![AllanLusui](https://dhis2.b-cdn.net/user_avatar/community.dhis2.org/allanlusui/32/48813_2.png) [@AllanLusui](https://community.dhis2.org/u/AllanLusui)\
**Post date:** [3 November 2026 10:04 UTC](https://community.dhis2.org/t/validation-rule-triggering-on-local-server-but-not-on-cloud-server-right-side-value-unexpected/77820/3 "2026-11-03T10:04:38Z")

</div>

Hi Fidele  
I had gone through all the suggestions you had mentioned. unfortunately none of these solved the issue.  
We have however found a temporary solution to the issue.Once someone runs a validation in the DHIS2 Validation app, the results are pushed into the `validationresult` table in the DB and the results stored here seem to persist regardless of how many times a new validation rule analysis is run.  
We went into the DB, checked the results, and noticed that truly these values are exactly what the entry app was reporting(local server)

`select validationresultid,leftsidevalue,rightsidevalue from validationresult where organisationunitid=(select organisationunitid from organisationunit where name ='OU_NAME');`

 ![image](https://dhis2.b-cdn.net/uploads/default/original/3X/4/1/41e8d058206a69bc45c21e66b199ebc8b68ae511.png)

The same values were not available in the destination server(prod) and this is why in our prod no error was being thrown

We then proceeded to delete these values from the local DB, rerun the VR analysis and no error was now thrown on the local.