Radicore Forum
Fast Uncompromising Discussions. FUDforum will get your users talking.

Home » RADICORE development » Bug Reports » Update Multiple Scroll Sequence Behavior
Update Multiple Scroll Sequence Behavior [message #4294] Thu, 26 June 2014 08:50 Go to next message
kong is currently offline  kong
Messages: 90
Registered: December 2011
Member
Selecting several records in List1 and then clicking Update button will bring up detail screens for the selected records one by one for editing. And by clicking the Submit Next button, the current record will be saved and the next record will be presented, etc.

However, I noticed that sometimes, after updating a record and clicking Submit Next, the sequence of the selected records as associated to the scroll bar could have changed. This could result in some strange behavior like getting presented with already processed records after clicking Submit Next, while unprocessed records could have moved up in the sequence and hence will not be presented in subsequent Submit Next's. There is no way to tell where unprocessed records might be hiding in the sequence, other then by going through all the records again one by one.

I suspect this has to do with the way each selected record for update is read from the DB using a SELECT statement with OFFSET xx, where xx is the sequence in which records are linked to the scroll bar. This could result in 1) when a sort order is not defined in the SELECT statement, there is no guarantee that the order of returned records for the same set of records SELECT will be in the same order every time (I noticed this especially in PostgreSQL) and 2) when a sort order is defined and an edit/update of a record changed the value of a field that was part of the ORDER BY clause then this could dynamically change the sequence as well.
Re: Update Multiple Scroll Sequence Behavior [message #4297 is a reply to message #4294] Fri, 27 June 2014 05:35 Go to previous messageGo to next message
AJM is currently offline  AJM
Messages: 2347
Registered: April 2006
Location: Surrey, UK
Senior Member
You need to have a sort order defined in the LIST screen so that after making several selections and passing control to a child screen, which shows the selected entries one at a time, the same sort order is preserved. If you do not specify a sort order then the results could be returned in any random order.

Re: Update Multiple Scroll Sequence Behavior [message #4308 is a reply to message #4297] Sat, 28 June 2014 01:54 Go to previous messageGo to next message
kong is currently offline  kong
Messages: 90
Registered: December 2011
Member
Yes, I got that. Still remains the second problem when a field to be updated happens to be part of the ORDER BY clause, it will mess up the sequence dynamically. I think a more intuitive behavior would be: (1) During update of selected records, the records should be ordered in the same sequence as shown in the List1 screen from which the records where selected. (2) This order should be fixed and be applied for the selected records during the whole process of updating and scrolling through them, no matter what fields get modified in the process.

This behavior is probably more complicated to implement than using the SELECT...ORDER BY...LIMIT 1 OFFSET xx to obtain selected records one by one, so I won't complain if this does not make the TODO list for now Razz
Re: Update Multiple Scroll Sequence Behavior [message #4310 is a reply to message #4308] Sat, 28 June 2014 04:52 Go to previous message
AJM is currently offline  AJM
Messages: 2347
Registered: April 2006
Location: Surrey, UK
Senior Member
The only way to retrieve records in a known and repeatable sequence is to use an ORDER BY clause in the SELECT statement. If the update changes one of the fields in the current sort order, then the SELECT ... ORDER BY ... will return the records in the latest sequence, not the previous sequence. This is behaviour that I cannot change.

Previous Topic: Error update column to popup with Postgresql
Next Topic: Cannot create Multi6 in v1.84
Goto Forum:
  


Current Time: Fri Mar 29 10:49:35 EDT 2024

Total time taken to generate the page: 0.00902 seconds