Hello,
Just to better understand. About the list from SQL output... Someone can let me know:
1. what would this new element ( initialized with default values) be?
2. "A default element if the list is empty ". It means, the message" No items to show... " on the screen when the list is empty?
3. I´ m a little confused with these descriptions:
a) In what situation would the Current be after the last record on the list?
b) In what situation would the Current be prior to the first record on the list?
Best Regards,
Jessica Marques.
Hi Jessica,
I'll try to answer your questions:
1 and 2. The Empty attribute is true if the the list is empty / no records; false otherwise. What I thinks it making confusion is the part of the default element.
When you are iterating a list, you use the Current position (e.g. GetUsers.List.Current.User.Id) which starts at 0 and goes through your list until Length - 1 (e.g. if your list has 5 elements, the Current element / CurrentRowNumber will range from position 0 to 4).
When that list is empty, you can still access the Current element. What happens is that Current, has all its attributes empty. Imagine your query returns a record from the table User and that query is empty, your Current record will have Id 0, Name "", creationDate 1900-01-01, Is_Active False. That's what the documentation mean by the default record in Current position.
3. Those descriptions are indeed confusing so my explanation goes towards what I have experienced so far. Basically the BOF will be True when your current number is 0 (first element) and the EOF will be True when your current row number. In the example below, you can see some information from a debug snapshot, where the EOF is True and the CurrentRowNumber is 3 (4th element of the list, thus the last element) and BOF is False, because it is not the first one in the list (it would be True if CurrentRowNumber would be 0):
Hope it helps.
Regards,João
Yes, João Marques helped a lot.
Now it makes more sense to me since when we are going to iterate a list the first item in that list is commonly in programming considered as position [0]. should that’s why they describe it as before the first.
----------------------------------------------------------------------------------------------------------------------------------------------
Here in the SQL Output is it the same relation as the aggregate output?
Anyway, is it the same with SQL?
Count and Length are not the same things in aggregate. When you do an aggregate attached to a list, you can define MaxRecords (imagine, if you have a table of millions of records but you want the first page with 20 records, you don't need to fetch a million rows from the database) and your list has 20 records and the length is 20. The count however would be the million rows, it's fetched on a different query and the default pagination use it (to know the total amount of records and number of pages). Those are two queries, one gets the 20 records and it has the length 20, and the other one has the Count (millions in my example). The query for the Count is only executed if you use the Count (for instance, if you don't have pagination).
This optimization from the platform I mentioned is only available for aggregates binded to lists / table records. In Advanced SQL, if you set MaxRecords, the Count will also be cut to those MaxRecords.
You can also read the difference in this post.
Best regards,João
Hi João,
Thanks for the information, I think I was not clear on my question. I understand that the count and the length in the aggregate are different (Thanks for the indicated post, I will read it)
I am sorry I hadn't understood and still not sure if I understand. When you mean SQL, do you mean an Advanced SQL as oppose to an aggregate?
For the difference, between the two, Jorge Martins explains it better, way better than I had above (taken from the post mentioned above):
The scenario I meant for Advanced SQL is the following: when you set MaxRecords property, you are not really optimizing the query since the query will be sent to the database and pull all the records from the database. So it is very common and a good pattern to use the TOP (@NumberOfRecords) - in SQL Server - to optimize the query and only get the necessary records. But in that case, the Count of that query will also be affected unlike Aggregates.
So what is usually done to optimize the scenario of pagination using Advanced SQL, is having a query with the TOP that feeds the list and another one separate with a COUNT(1) to retrieve the total number of records. Here's an example of a Preparation in Traditional Web with a complex query that demands the use of an Advanced SQL:
Hi João Marques.
Perfect! Thank you very much for your attention and very clear and detailed explanation, you have no idea how it helps me.
I'm glad I could help Jessica!
At one point or another, we all had this exact same question :)