ISAM vs SQL CURSOR
Posted: Wed May 08, 2019 12:09 pm
Most of the beta testing, up to now, has been with Richard Covington's app.
His browses always start out as an SQL cursor (less common) rather than ISAM (most common).
When your DCBROWSE uses the SUBCLASS 'DC_XbpBrowseFiltered()' clause and your columns use the SUBCLASS 'DC_XbpColumnFiltered()' clause and you use the SQLSORT clause on the column, then you will get different behavior if your workarea is a SQL cursor rather than just an ISAM workarea.
When left-clicking on the SORT button in the header of a column, you expect the browse to sort by that column.
If the work area is a SQL CURSOR then that is done by modifying the SQL statement and adding the ORDER BY clause to the end of the statement and re-executing the statement in the current work area.
If the work area is a standard ISAM, then it is expected that it will work as it always has in the past and your SORT clause will determine the sort method, most commonly OrdSetFocus().
Everything changes, however, when a user right-clicks a heading and chooses a filter for a column. This action replaces the current workarea with a SQL CURSOR in order to use the SQL WHERE clause to filter the data set. Whenever any column is filtered, there are no more indexes available because the work area is now a SQL CURSOR. This means that clicking on a column that has a SORT by an index tag will fail and the column will not be sorted. The workaround for this scenario is the following:
Here is an example of Bobby Drakos code where I made it work both ways:
His browses always start out as an SQL cursor (less common) rather than ISAM (most common).
When your DCBROWSE uses the SUBCLASS 'DC_XbpBrowseFiltered()' clause and your columns use the SUBCLASS 'DC_XbpColumnFiltered()' clause and you use the SQLSORT clause on the column, then you will get different behavior if your workarea is a SQL cursor rather than just an ISAM workarea.
When left-clicking on the SORT button in the header of a column, you expect the browse to sort by that column.
If the work area is a SQL CURSOR then that is done by modifying the SQL statement and adding the ORDER BY clause to the end of the statement and re-executing the statement in the current work area.
If the work area is a standard ISAM, then it is expected that it will work as it always has in the past and your SORT clause will determine the sort method, most commonly OrdSetFocus().
Everything changes, however, when a user right-clicks a heading and chooses a filter for a column. This action replaces the current workarea with a SQL CURSOR in order to use the SQL WHERE clause to filter the data set. Whenever any column is filtered, there are no more indexes available because the work area is now a SQL CURSOR. This means that clicking on a column that has a SORT by an index tag will fail and the column will not be sorted. The workaround for this scenario is the following:
Here is an example of Bobby Drakos code where I made it work both ways:
Code: Select all
DCBROWSECOL HEADER "Driver's Last Name" ;
DATA {|| DRV->last } ;
PARENT oBrowse WIDTH 13 ;
TOOLTIP "Last Name Of The Driver;Right Click To Set Last Name Order" ;
DATATOOLTIP {||.T.} TIPBLOCK {|| _toolTipAddr() } ;
SORT _colSort('DRVLAST', GetList) ;
SUBCLASS 'DC_XbpColumnFiltered()' ;
SQLFIELD 'LAST'
The static function _ColSort() was changed as follows:
WAS:
STATIC FUNCTION _colSort(cTag, GetList)
RETURN {||DRV->(OrdSetFocus(cTag)), ;
DC_GetRefresh(GetList,'SAYSEEK' ), ;
PostAppEvent( xbeP_Keyboard, xbeK_CTRL_S, nil, )}
IS:
STATIC FUNCTION _colSort(cTag, GetList)
RETURN {|o,n|DRV->(OrdSetFocus(cTag)), ;
IIF(DRV->(OrdSetFocus())==cTag,nil,o:orderBy(n)), ;
DC_GetRefresh(GetList,'SAYSEEK' ), ;
PostAppEvent( xbeP_Keyboard, xbeK_CTRL_S, nil, )}