32
Views
6
Comments
Solved
Different SQL query results in Test vs Runtime (same query and parameters)
Question
Application Type
Reactive
Service Studio Version
11.55.35 (Build 64305)

Hi everyone,

I’m facing an issue with an Advanced SQL query in OutSystems. When I run the query in Test Values inside Service Studio, I get 86 rows. However, when I run the exact same query in Runtime, with the exact same input parameters (EntityNameId = 51 and EspaceId = 57), I only get 1 row back.

  • The query text is identical in both cases.

  • The input parameters have been triple-checked and are the same.

  • I have the same problem in a normal Aggregate

Has anyone encountered this behavior before? Why would Test Values and Runtime produce different results with the same query and parameters?

Any pointers would be greatly appreciated!

The query I am using:

SELECT ENENTITY_2.[Name], 0 ,ENENTITY_ATTR.[Name],ENENTITYNAMES_2.[id],ENENTITY_ATTR_2.[name],1

FROM ((((({Entity}    

INNER JOIN {Entitynames} as ENENTITYNAMES ON (ENENTITYNAMES.[Label] = {Entity}.[Name]))     INNER JOIN {Entity_Attr} as ENENTITY_ATTR ON ({Entity}.[SS_Key] = (substring(ENENTITY_ATTR.[Type], (((charindex(N'*', ENENTITY_ATTR.[TYPE]) -1)) + 1) + 1, 100))))     

INNER JOIN {Entity} as ENENTITY_2 ON (ENENTITY_ATTR.[Entity_Id] = ENENTITY_2.[ID]))     

INNER JOIN {Entitynames} as ENENTITYNAMES_2 ON (ENENTITY_2.[NAME] = ENENTITYNAMES_2.[LABEL]))     

INNER JOIN {Entity_Attr} as ENENTITY_ATTR_2 ON ((ENENTITY_2.[ID] = ENENTITY_ATTR_2.[ENTITY_ID])    AND (ENENTITY_2.[PRIMARYKEY_SS_KEY] = ENENTITY_ATTR_2.[SS_KEY]))) 

WHERE ([ENENTITYNAMES].[IS_ACTIVE] = 1)  AND ((ENENTITYNAMES.[ID] = @EntityNameId) AND ([ENENTITYNAMES].[ID] IS NOT NULL))    AND (({Entity}.[Espace_Id] = @EspaceId) AND ({Entity}.[Espace_Id] IS NOT NULL))

We have a static entity called {Entitynames} in this static we added a the entities we use in the application

UserImage.jpg
Stefan de Vaan
Solution

Hello everyone,

I have fixed the bug.

The issue was not in the SQL query itself, but in how it was being used.I solved it by creating a new test application and adding a dependency to the server action that contains the SQL query.

After doing this, the query started returning the expected values.

I’m not 100% sure why this happens, but apparently without the dependency the server action wasn’t being resolved correctly, which caused the query to behave differently.

Hopefully this helps anyone who runs into a similar issue!

Edit: good to add, is that we didn't make use of multi-tenant

2026-01-28 16-57-48
Mihai Melencu
Champion

Hi @Stefan de Vaan ,

Did you check the StartIndex & MaxRecords properties on the query/aggregate? Make sure there is no limit at runtime.

UserImage.jpg
Stefan de Vaan

Hi @Mihai Melencu ,

I dont use a startindex or maxrecords.

2026-01-28 16-57-48
Mihai Melencu
Champion

Are any of your entities set to multi-tenant?

Also, could you share your OML or recreate the use case in a sample OML for us to review? 

2025-08-07 06-30-56
Amit J
Champion

I think, If your static entity {Entitynames} is shared, but the main {Entity} is tenant-specific, then Runtime applies the tenant filter and only returns rows for the current tenant. In Test Values, no tenant filter is applied, so you see everything. Otherwise you can share sample oml with similer data.

2016-04-22 00-29-45
Nuno Reis
 
MVP

Hello.

One more option. When you say runtime is what you see on the screen or in debug? Because the debug in runtime may hide records not in use, not calculate length, and so on. It will get exactly what it needs, not what you want to see.

UserImage.jpg
Stefan de Vaan
Solution

Hello everyone,

I have fixed the bug.

The issue was not in the SQL query itself, but in how it was being used.I solved it by creating a new test application and adding a dependency to the server action that contains the SQL query.

After doing this, the query started returning the expected values.

I’m not 100% sure why this happens, but apparently without the dependency the server action wasn’t being resolved correctly, which caused the query to behave differently.

Hopefully this helps anyone who runs into a similar issue!

Edit: good to add, is that we didn't make use of multi-tenant

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.