Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


Tip of the Day
Language: SQL Server
Expertise: Beginner
Feb 27, 1997

Result Sets Are Not Active Error

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:

- SqlFetchNext
- SqlFetchRow
- SqlGetResultSetCount
The FERS files are written to the TEMP directory on the PC (usually set to c:\windows\temp 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.

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\temp).

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.

DevX Pro
 
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date