Question:
My SQLWindows app, which has been deployed for several months now, has started giving error 163 (“Result sets are not active”) messages. Is this caused by a bug somewhere in the app, or something environmental?
Answer:
Centura provides native connectivity routers (and ODBC access) to all popular RDBMS brands like Oracle, Sybase, SQLServer, Informix, DB/2, etc. One of the features provided by those routers is “front end result sets” (FERS). Every time data is read from the backend, a copy of the data is written to the PC’s disk. This enables backward scrolling capability, a feature that is normally missing in the backend. SQLBase, by the way, supports this as a native feature (by formulating a scrollable result set on the backend).
FERS enables the following function calls to be made from the app:
– SqlFetchNextThe FERS files are written to the TEMP directory on the PC (usually set to c:windows emp in your AUTOEXEC.BAT). These files are named as FRSn, where n is an integer. The router takes care of purging these files as soon as they are not required anymore.
– SqlFetchRow
– SqlGetResultSetCount
There are certain instances, however, when these files may linger “orphaned” — typically under abnormal termination conditions (affectionately known as “GPF” in Windows parlance). Consequently, there may come a time when the TEMP directly could have hundreds of these FERS files. Under some circumstances, the router could have trouble creating a new file in the same directory — even DOS has a limit to the number of files that can be created in a directory. Or the disk itself may run out of space. This is when you start noticing error 163 — the router is informing you that it could not create a result set file for you.
The solution is simple: every time you boot your PC, clean up your TEMP directory. Better still, put the cleanup into your AUTOEXEC.BAT (echo Y | del c:windows emp).
On a more strategic note though, most of your application could do without using FERS altogether! You see, when you populate a listbox, you don’t need this feature. And a table window can contain up to 32K rows anyway, which should be more than sufficient in most cases. So, the trick is to use FERS with DISCRETION. This feature can be turned off globally by the following code:
On SAM_AppStartup Set SqlResultSet = FALSE
FERS can also be set on a per cursor basis:
If SqlConnect ( hSql) Call SqlSetResultSet ( hSql, FALSE )
For complete information on these functions, check your on-line help.
