I'm seeing a stange difference in behaviour between these two methods.

I have two dialogs each consisting of two grids each and then shuttle buttons inbetween so that the users can select rows and move them down to a "cart" for later processing. On one of the dialogs we've made the top grid "infinte scroll" as by default it returns 21k+ rows (I know, but the users really want to have them all come back initially, then apply filters) and without doing this we were getting a performace isssue.

So following along with the demo on the formspider website for the "shuttle buttons" we got the functionality we were after within the dialog that contains the standard grid, users can happily shuttle records up and down. On the dialog where the top grid is set to infinte scroll the records can be moved down into the bottom grid succesfully, but when the user moves the row back up, it is not being created in the top grid.

I've debugged the app and can see the api_datasource.createrow line fire, but nothing gets created and if I filter for it the row just copied up it does not find anything.

messing around with this I discovered if I use

my_PK := api_datasource.getcolumnvaluetx('datasource.column');
v_rowid := api_datasource.createrow(in_datasourcename_tx => 'datasource_name',in_nextsiblingpk_tx => my_PK);

I can get a row to be inserted in the top of the block, but when I then reorder the grid in order to get the row back where it belongs it disappears or appears to.


asked 10 Nov '15, 03:31

apacheuk's gravatar image

accept rate: 0%

Hi Simon,

Operations like reordering and filtering cause a datasource with infinite fetch mode to execute its query and repopulate itself. Is the fetch mode set to Query As Needed? Could you please try with Query All? I haven't tried it now myself, but that might work as you expect.

There is actually a reason for infinite scroll with fetch mode query as needed to work this way :-) : In this mode, the datasource only has some of the rows in it that it could receive from the result set of its query. So say when you first fetched 10 rows ordered by name, and now you want to order the rows in the datasource by ID. There may be rows in the result set that you have not fetched yet which may be included in the first 10 rows when you order the result set by ID. Not showing them can be very misleading. So FS executes the SQL of the datasource losing any modifications made to it.

This problem doesn't exist if all the rows in the result set are stored in the datasource. In this case, FS treats the rows in the data source like a cursor result set, a consistent view to the database. There still may be inconsistencies, (someone might have changed a row or deleted one or inserted a new one after the execution of the datasource SQL) but Formspider delegates issues related to these events to concurrency and business logic API's.

Querying 21K rows might be OK if you don't have too many users doing this operation at the same time. The performance issue probably comes from the rendering of 21K rows not storing them in the datasource.

Hope this helps.

Kind Regards


answered 10 Nov '15, 04:08

Yalim's gravatar image

Yalim ♦♦
accept rate: 20%

edited 10 Nov '15, 04:09

All makes perfect sense :)

I figured it would be something like that, I'm gonna change the design slightly so its less apparent to the users and work around the issue.

Cheers Simon


answered 10 Nov '15, 10:00

apacheuk's gravatar image

accept rate: 0%

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported



Asked: 10 Nov '15, 03:31

Seen: 33,630 times

Last updated: 10 Nov '15, 10:00

© Copyright Gerger 2017