Query returns only one record

Query returns only one record

  
Hello Guys,

I got a static entity with 8 records  created at design time. I then use Query Node to get back the record list which I want to save it to a variable and display in a combo box. But the query node always returns only one record. When I do a Test inside the query node, it does return all 8. Tried advanced query, still same issue. Any thoughts?

Thanks,
Raghu Kannan
Funny thing ... I had the same issue with a simple query.
6 records in the test, Length=1, Count=6 display only 1 .... :-)
Created a new page, new query and now things are OK ...

This was in ServiceStudio v6.0.1.19
Hi Raghu,

That happens because the query is optimized. (see the -optimized- next to the Lenght?)
In debug there are situations where you cannot see all the values of the query, but it will show correctly when iterated, displayed on a table or assigned to a recordlist variable.

I can't see the rest of the logic in just that screenshot, but why do you need to even do logic in the preparation to fill a combo box?
If you just fill the source entity (leaving the Source Record empty) it correctly fills the combo-box automatically for you without any query.

Joop:
If your query has an Max Records = 1 or the optimizer decides you only need 1 line, then its like that.

Count is the total amount of records that would be returned if there was no line limitations.
So in normal situations where data is showed in screens (this is, not being fully iterated due to record limitations) Count != Length.

Also note that if you use the .Count of a query, it actually does the queries 2 times to give you both values. So its more efficient to always use the Length unless for pagination purposes or if the query is really only used to Count (data not iterated).

Regards,
João Rosado
@Joao: nope, mine doesn't have any limitations on query, tablerecord or wherever.
I solved it by creating a new screen with a new (same) query and now it displays the correct number of rows.
João Rosado wrote:
Hi Raghu,

That happens because the query is optimized. (see the -optimized- next to the Lenght?)
In debug there are situations where you cannot see all the values of the query, but it will show correctly when iterated, displayed on a table or assigned to a recordlist variable.

I can't see the rest of the logic in just that screenshot, but why do you need to even do logic in the preparation to fill a combo box?
If you just fill the source entity (leaving the Source Record empty) it correctly fills the combo-box automatically for you without any query.

Joop:
If your query has an Max Records = 1 or the optimizer decides you only need 1 line, then its like that.

Count is the total amount of records that would be returned if there was no line limitations.
So in normal situations where data is showed in screens (this is, not being fully iterated due to record limitations) Count != Length.

Also note that if you use the .Count of a query, it actually does the queries 2 times to give you both values. So its more efficient to always use the Length unless for pagination purposes or if the query is really only used to Count (data not iterated).

Regards,
João Rosado
 
  Hi Joao,

For some reason the record list didn't show up in the combo box either, even after publishing the eSpace. Never seen anything like this before. The reason I had to manipulate the data set is based on the type of insurance, I only need to display a subset of the record list retrieved from the static entity. That's why I couldn't put the static entity straight in the combo box parameters.

However, I found another old post wherein it was mentioned this was a bug in version 4 which has been resolved. Not sure why it has come back to haunt us. :)

But the solution given at that time was to assign the output of the query to a session variable. I did just that. Created a dummy session variable and assigned the query output to it before I start to manipulate the data. Guess what, it worked. Bit strange though. I do realize having a session variable of data type records list is not ideal, but I can't find a better alternate to get this to work. Also I think (I may be wrong) 8 records in a session variable  is kind of ok.

Cheers,
Raghu Kannan