Query record without a relationship

Hello michszym,

You can create do that using a!queryRecordType().  Create two records for each of your source.

Let's say you are using it in a dropdown field. 

From my understanding you want to display the Employee Name from Executed jobs table and on selection you would like to show data from Hourly rates of employees. 

Create a query for your Executed jobs record type and make sure you get only the data. Create another record type query for your Hourly rates of employee record and make sure you have a filter for the employee field. 

you can add filters and give the operators such as between.

You can now call your Executed Jobs record query in a local and try indexing the name of the employee as your dropdown Choice values and Choice labels. 

consider another local variable for the selected employee name.

Call your Hourly rates of employee in a local variable and in that rule you need to pass the variable where you are saving the dropdown selection value. You can add multiple filters to your query and have dropdowns for passing all the values. 

a!localvariables(
local!employeeTable: rule!yourEmployeeQuery(),
local!selectedEmployee,
local!hourlyRates:rule!hourlyRates(employeeName: local!selectedEmployee),
{
a!dropDownField(
label:"Select Employee",
choiceValues:index(local!employeeTable,"recordType!field",null),
choiceLabels:index(local!employeeTable,"recordType!field",null),
value:local!selectedEmployee,
saveinto:local!selectedEmployee,
placeHolder:"Select"
),

a!sectionLayout(
contents:{
display your data by indexing the field from local!hourlyRates
}
)
}

)

Make sure you have a null check for the filter/parameter.

I'm not sure if this is what your question was about. Please ignore if not.

Hope this will help.

Hi Konduru.
Thanks for the reply, but that for me is not a valid solution. First of all I'm trying to display values and not get inputs. Both ways (for read/display and input) it does work for a small amount of record, and there it is valid. Cause let's say for 5 jobs shown, you are executing 1 query to retrieve these jobs, and then 5 other queries to retrieve dropdown content for each of the job entries. But imagine you have 500 jobs to display on a graph, or to build a calculation? Or a thousand of them. That would mean 501 queries or 1001. And that, even if it does the job, I would say would be not optimal - both in terms of operations needed and in terms of time needed to execute all of them.

So thanks again, but I'm still open for suggestions and answers how to tackle that.

Hi michszym, I Think it will query only once and it will give us the desired output. Since you will be selecting the value from the dropdown your query will run only once and will give you the data. You can use this data to display the values. 

If it just for display, one possible solution is to use your SQL query to create a view, and make new record type and make the CDT of your view as source of data. or maybe just use queryEntity if it's possible for your use case.

Hi Eunnel.
Thanks for the reply. All your points are valid and would work, but my question is just touching the surface of the problem, and with the full problem behind it, it's impossible to achieve.

In fact what we have is three tables:
A - table listing jobs
B - table listing job actions, each job action can have a different executor, all with have some execution timestamp with it
C - table listing executor wages with a wage value and time where given wage started to be effective

Originally, we are using queryEntity. But this is somehow limitting for us - we want to display a requested number of jobs with all their job actions and cost of them. And you can't put a limit on the jobs and at the same time retrieve a various number of job actions with them. ...or at least that's how I see this. If you create an entity of joined A + B + C, you are putting a row count limit on result of such cartesian multiplication. Hence limiting to ten, you may get two jobs (one with 4 actions, the other with 6 actions) and that's it.

Hence queryRecordType gives a huge benefit of being able to limit on the jobs, and then add related record type data from job actions. So in the end you can say 'give me 10 jobs, with their job actions, regardless how many job actions they have'.

local!testData: a!queryRecordType(
 recordType: 'recordType!A',
 fields: {
   recordType!A.fields.someField,
   recordType!B.fields.someOtherField,
 },
 relatedRecordData: {
   a!relatedRecordData(
     relationship: 'recordType!A.relationships.B',
     sort: {
       a!sortInfo(
         field: 'recordType!B.someOtherField',
         ascending: true
       )
     }
   )
 },
 pagingInfo: a!pagingInfo(
   startIndex: 1,
   batchSize: 10,
   sort: {
     a!sortInfo(
       field: 'recordType!A.fields.someTimestampField',
       ascending: true
     )
   }
 )
 ).data,

And here, correct me if I'm wrong, but records from a CDT, so records without sync enabled, will not allow you do add relationships, right? hence no possibility to add related record data (relatedRecordData inside queryRecordType).

...or at least that's how I'm seeing it. If I'm wrong at any point, feel free to point it out to me.
Regards
Michael

Maybe you are right, and this could work. But we are not using it in a grid with dropdown. I want to display stuff in a chart, with also summary and avarage values displayed. So this dropdown option is out of consideration I'm afraid.