The behavior of Previous/Next buttons and the navigation bar

eugenio

Administrator
Staff member
Dear all,
I have added a new chapter to the documentation, explaining why this behaviour could be unexpected for the final users of our applications. I have been thinking about better ways to handle these features since quite a long time ago but I haven't found any satisfying solution. I would be happy to hear your opinion here.

For your convenience and for future reference, I'll paste here the current content of the chapter.





22. Previous/Next buttons and page navigation bar, unexpected behavior

How do the "previous" and "next" record buttons work? How does the page navigation bar ("Page x of y") work?

It's important to understand how these features work because their behaviour could be unexpected for the final users of your application.

Let's start with the "previous" and "next" buttons, the buttons you can see when you click on the "edit" or "details" icon in the result grid to access, one by one, the records beloning to the current result set.

Let's say you have a table "cars" and you want to edit (or just see, one by one) all the cars having a price < 15000.

Imagine what you would do if your database was on paper (one paper sheet for each car): you could take from the folder all the sheets related to cars having price < 15000 (let's say there are 25 cars), modify them by changing some data (for example the price) and then put them back in the folder. When you take those 25 sheets, you are sure you are going through all the cars having price < 15000 and while you are working, nobody can take your 25 sheets or modify them.

What happens in your DaDaBIK app is a bit different. Let's say you search for cars having a price < 15000, you get your results (25 records), your order by price, you enter the first record (in edit mode), you modify the first record, then you click on "next", you modify the second record and so and so fourth. The total number of records you will go through could be 25 as expected but could also be less than 25 or more than 25. Why?

When you click on "next", the system re-executes the search query, find the position of the record you are viewing in the current recordset and then opens the record that, considering the current sorting, is immediately after that. If, while you are modifying the first record, someone adds a car having price < 15000, you could see this new record as a second, instead of the record you expected to see and you will finally go through 26 records instead of 25. If, while you are modifying the first record, someone deletes the second record, you will finally go through 24 records instead of 25. These two scenarios, however, are not problematic.

Let's see another case that is much more problematic: you modify the price of the first car, it was 7000 (the cheaper car, so the first record) and you change it to 14500 (one of the most expensive, let's say the 23th car): when you click on "next", you will see record 24 and then record 25 and you won't go through all the records between the 2nd and 22th.

Consider that on the recordset (cars having a price < 15000) you are working on, other users could also work at the same time (DaDaBIK provides a locking mechanism, but it prevents other users to edit the record you are working on, not an entire recordset you are working on!) so while you are editing the 3rd record, another user could change the price of the most expensive car (25th record) and make it the cheaper (1st record) so you won't see such modified car by using the "next" button, because you are already on record 3.

This is just an example but there are other cases of EDIT (made by the current user or other users) that can modify the current result set or the position of the records in the set and therefore if you are viewing, one by one, all the records belonging to your results set ("NEXT", "NEXT", "NEXT", ...), you could skip some of the records or you could see the same record twice.

This is not something easy to fix. In order to replicate what happens in the "physical" world, we should lock all the records belonging to your results set; this can be problematic, though, because maybe they are not free to be locked (other users are using them) and your results set could be so big that you need to lock the entire table.

The only safe way to work with "previous" "next" if your goal is to review all the records belonging to a results set is to sort the result by a field that nobody can modify and that you are not filtering on. Typically this field is the primary key of the table. It can still happen that some records disappear (because other users delete them) or some additional records appear (because other users add them) but at least you are sure you are not skipping records matching your search filter.

How about the page navigation bar? The behaviour is similar.

Let's say, again, that you search for cars having price < 15000, you get 25 results and you have 10 record per page. You want to give a short look at all the records, starting from the cheaper (you sort by price) without entering the edit/details pages; you stay on the results grid, you use the navigation bar and you assume you will see al the records.

After having read the first page (first 10 records) you click on page 2. While you are reading page 1, however, another user changes the price of the 11th car, which is now cheaper and gets position 10. Therefore, after having clicked on "page 2" link, you wont see the original 11th record, you will see again the 10th, and you will never see the original 11th (which is now on page 1).
Again, this is just an example but modifications made on the records belonging to the current result set can have an impact on the records you will see by clicking on the pages link.
 

eugenio

Administrator
Staff member
When I said solution, I meant changes to the way these features work OR simple and effective ways to inform (in the front-end interface) the final users about the behaviour of these features.
 
I think you mean 14500, if the (now) 23rd value is less than 15k.
I'm not sure there is an easy way to describe this. I have a paragraph in my docs about the failure to "Next" when the current record is edited and doesn't match the filter any more, but will have to add some more paragraphs describing you note above.
 

eugenio

Administrator
Staff member
LurkingKiwi Wrote:
-------------------------------------------------------
> I think you mean 14500, if the (now) 23rd value is
> less than 15k.
> I'm not sure there is an easy way to describe this
> . I have a paragraph in my docs about the failure
> to "Next" when the current record is edited and do
> esn't match the filter any more, but will have to
> add some more paragraphs describing you note above
> .


Sorry, yes, I meant 14500, I have edited the original post.

Probably the most important thing to point out is that if you (final user) are trying to go through a results set and want to be sure to see all the records (using prev/next or page navigation), you have to sort by ID (ASC).
 
Top