The result of executing a SQL statement is usually a resultset. A result set can be seen as a conceptual table that results from a query and that is available to an application in tabular form. SELECT statements, catalog functions, and some procedures create result sets. For example, the following SQL statement creates a result set containing all the rows and all the columns in the Orders table:
SELECT *
FROM Orders
This SQL statement creates a result set containing OrderID, SalesPerson, and Status columns for the rows in the Orders table for which the Status is OPEN.
SELECT OrderID, SalesPerson, Status
FROM Orders
WHERE Status = 'OPEN'
A result set can also be empty, which is different from no result set at all. For example, the following SQL statement creates an empty result set:
SELECT *
FROM Orders
WHERE 1 = 2
An empty result set is no different from any other result set except that it has no rows. For example, the application can retrieve metadata for the result set, can attempt to fetch rows, and must close the cursor over the result set.
In most situations, application programmers know whether the statements their application executes will create a result set. This is the case if the application uses hard-coded SQL statements written by the programmer. It is usually the case when the application constructs SQL statements at run time: The programmer can easily include code that flags whether a SELECT statement or an INSERT statement is being constructed. In a few situations, the programmer cannot possibly know whether a statement will create a result set. This is true if the application provides a way for the user to enter and execute an SQL statement. It is also true when the application constructs a statement at run time to execute a procedure.
In such cases, the application calls f90SQLNumResultCols to determine the number of columns in the result set. If this is 0, the statement did not create a result set. If it is any other number, the statement did create a result set. The application can call f90SQLNumResultCols at any time after the statement is prepared or executed. However, because some data sources cannot easily describe the result sets that will be created by prepared statements, performance will suffer if f90SQLNumResultCols is called after a statement is prepared, but before it is executed.
Some data sources also support determining the number of rows that an SQL statement returns in a result set. To do so, the application calls f90SQLRowCount. Exactly what the row count represents is indicated by the setting of the SQL_DYNAMIC_CURSOR_ATTRIBUTES2, SQL_FORWARD_ONLY_CURSOR_ATTRIBUTES2, SQL_KEYSET_CURSOR_ATTRIBUTES2, or SQL_STATIC_CURSOR_ATTRIBUTES2 option (depending on the type of the cursor) returned by a call to f90SQLGetInfo. This bitmask indicates for each cursor type whether the row count returned is exact , approximate, or not available at all. Whether row counts for static or keyset-driven cursors are affected by changes made through f90SQLBulkOperations or f90SQLSetPos, or by positioned update or delete statements, depends upon other bits returned by the same option arguments listed previously. For more information, see the f90SQLGetInfo function description.