LiveCode Forums.

I have two questions:

A) With RR, is it possible to view a recordset (say containing 3500 customer addresses) over multiple pages with first page, previous page, next page and last page navigation type functionality. So maybe each page would contain 50 records (or whatever) and then we simply click the 'next page' link to browse through and view the next 50 records etc etc.

B) If the answer to question A is yes, are there any samples out there on how this maybe achieved...can anyone point me in the right direction.

If so, throw me a line...it would be much appreciated.

Thanks in advance!

While I don't really have an example to give you, I do think this would be possible by retaining the result set ID and refreshing the card - filling fields and other controls with data from the next 50 records from a mouseUp handler in your navigation buttons.
Revolution isn't like your average web application development environment, though - we tend to use table fields to display everything in one go, and let the user scroll. And then as a user selects a line in the table field, we update the detail part of the form.

Fields can contain tens of thousands of lines with negligible performance impact. So the bottleneck in that scenario is getting the data from the database into the Revolution memory space.
One of my tricks is to not use the revDataFromQuery function to get all the data in one go, but use the revQueryDatabase function instead to get a cursor, and then fetch the records + update the table field in blocks of 20 records using a 'send in time' construct.

Which brings us right back to your paging question. The revQueryDatabase function returns a result set ID, aka cursor ID. This ID is the key parameter in the following functions, which I'm sure you'll want to look up in the docs: revCloseCursor command, revCurrentRecord function, revCurrentRecordIsFirst function, revCurrentRecordIsLast function, revDatabaseColumnCount function, revDatabaseColumnNamed function, revDatabaseColumnNames function, revDatabaseColumnNumbered function, revDatabaseColumnTypes function, revMoveToLastRecord command, revMoveToNextRecord command, revMoveToPreviousRecord command, revNumberOfRecords function.

Hope this gets you started,

Jan Schenkel.

Janschenkel wrote: So the bottleneck in that scenario is getting the data from the database into the Revolution memory space.

One of my tricks is to not use the revDataFromQuery function to get all the data in one go, but use the revQueryDatabase function instead to get a cursor, and then fetch the records + update the table field in blocks of 20 records using a 'send in time' construct.

Could you elaborate please about this memory issue.

-revDataFromQuery puts the datas into a variable
-but it's the same for revQueryDatabase

Both should use the same amount of memory ? No ?

Actually, depending on what you do with the data, revQueryDatabase may use less memory than revDataFromQuery:
- revDataFromQuery gets the entire set of data as one chunk of text - effectively combining the data from the fields into a long long string;
- when you use revQueryDatabase, you only get a reference to the data, and you read little bits one at a time (one record at a time, one column of the record at a time)

Of course, if you're stuffing everything into a single scrolling field for display, your Revolution application will use exactly the same memory to represent the field content.
The main issue here is the time it takes to transfer the data from the database management system into Revolution's memory partition:
- with revDataFromQuery you have to wait until all the data has come through the pipe from the database to Revolution before you can display anything on screen;
- with revQueryDatabase you get back the reference and then add twenty lines of data at a time semi-asynchronously using a 'send in time' construct, which means that your application is more responsive to the user (which is generally considered A Good Thing)

As a bonus, you may be saving time and memory if the user finds the piece of data he was looking for in the first chunks of data that come through the pipe.
Think about it: when you're searching for a record, are you going to scroll through 2000 lines in a table? Chances are that either the record you're looking for is in the first two 'pages' of the table field, or you'll close the screen and go back to the selection screen and run a different search to limit the amount of data you have to wade through.

And in such a scenario, a 'send in time' construct can be cancelled and the resultSet closed before all the data has been transferred from the database to Revolution.

Hope this clarified it a bit,

Jan Schenkel.

Janschenkel wrote: Hope this clarified it a bit,

Indeed.

I just started with mySQL and Revolution, so I was not thinking about very large record sets.

Right now, lazy, I put everything into a single table field.

Anyway, i'm having a great time.