#445 Scrollable cursors not working

[Campbell Morrison]

This is a bug that doesn't affect any MRBS functionality, as far as I am aware, but is a bug in the DB and DBStatement classes.

The bug is is that DBStatement->row ($i) and DBStatement->row_keyed ($i) ignore the value of $i, and just return rows in the order in which they appear in the query result. Apart from the code for exporting iCalendars, which has now been fixed (see https://sourceforge.net/p/mrbs/support-requests/1865/), I don't think any MRBS code tries to do anything other than fetch the rows sequentially, so there aren't any defects in MRBS as a result. However if someone tries to use these methods other than sequentially the results will be unexpected.

I think there are two problems: (a) PDO::FETCH_ORI_ABS will only work if you “set the PDO::ATTR_CURSOR attribute to PDO::CURSOR_SCROLL when you prepare the SQL statement” (see https://www.php.net/manual/en/pdostatement.fetch.php), which we’re not doing and (b) that as far as I can see scrollable cursors aren’t supported by the PDO MySQL driver anyway and are just silently ignored. That said, I couldn’t get them to work with PostgreSQL either: setting the PDO::ATTR_CURSOR attribute to PDO::CURSOR_SCROLL just seemed to give me no rows returned at all from the query.

[John Beranek]

I think when I first saw this behaviour in the MRBS DB abstraction I did consider it a bit odd, as other Db astractions I've used in the past only offer methods to get the next row, and don't rely upon the caller to step through the rows they want.

I'm therefore not surprised that DB drivers (in this case PDO drivers) don't support this random access to query results - after all, the database does generally just return all the rows you ask it to in a very serial way, as I understand it.

So, I'd agree that we should probably take the 'row' methods in DBStatement and just make them, say:

->next_row()
->next_row_keyed()

[Campbell Morrison]

Now fixed in the default branch.