In some cases it is useful to start a new query (i.e. retrieve a new result set) in the middle of processing an existing result set. You can have up to 16 such result sets active at once, provided the operations on each are differentiated by the value of the reshdl field in the cmdhdr structure, and subject to the following limitations and considerations:
As of this writing (Sep 30, 2010), multiple result sets are only supported with the MySQL connector, and only then when not using QRYF_NOSTORE.
Although each result set is identified by the reshdl field (which is therefore the only field you absolutely must change in the cmdhdr when switching between result sets), several of the other fields may be directly or indirectly associated with the result set. Thus it may be better practice to use a completely separate copy of the cmdhdr structure for each result set, rather than have to deal with the possible sources of confusion in the other fields. But if you prefer to work with just one cmdhdr structure, here are some fields to watch out for:
cmdarg1 must be set appropriately prior to each SQLOP_FETCH_ROW operation (in the second and third syntax forms), and the required value will almost certainly differ between result sets (requiring you to save/restore it for each switch).
cmdarg2 can be left at zero when switching between SQLOP_FETCH_ROW operations on different result sets if you are always using the “fetch next row” mode. But if you do set it to a specific value in order to read a specific row, you must make sure to reset it appropriately when switching between result sets, lest you inadvertently jump over records in one or another of the sets.
info2 normally returns the row # just read after a SQLOP_FETCH_ROW call. In the case where you explicitly set the row number to read (in cmdarg2), info2 will simply be set to match it. But in the “read next row” case (where cmdarg2 is set to 0), ASQL assumes that the previous row number is in info2, and thus can just increment it to return the next row. Unfortunately there is no other easy way to query the database to determine the row number just fetched. So if you switch between result sets by changing the reshdl field, info2 either needs to be saved/restored with each switch, or otherwise ignored on output (as it will no longer be meaningful).
opflags may well need to be set/reset when changing from one result to another.
