Re: prepare,declare,open,fetch:Need some clues

: mkuhn@rhlab.UUCP (Michael Kuhn) writes: : I have found the thing that "breaks the bank" as it were. : : If I include this create table and drop table in my problem module : then the program : : create temp table calc_method_set(lab_case_id integer, : person_id integer, : system char(8), : relationship char(3)) : . : . : . : drop table calc_method_set : : will do one of two things when I execute it: : : 1. It will run completely and the "fetches" described in the earlier : post will not retrieve what they are supposed to. : : or : : 2. Programs stops with the following error. . . : : SQL statement error number -245. : Could not position within a file via an index. : SYSTEM error number -103. : ISAM error: illegal key descriptor (too many parts or too long). : : : I have obviously hit some sort of limit. : : - There are a quite a few temp tables involved. : : - The executable is 3.6mg and includes probably hundreds : of separately linked object files. : : - In addition it as the TCL interpreter linked in along with ESQL/C : access routines to allow TCL to get data from SQL. : : To try and figure out what limit I am up against is some what of : a problem. : : I need some clues? Thanks for taking the time to read this. For your information we have OnLine 7.10.UC1 on SCO Unix 3.2.4.2 In this version there is an ugly bug with temporary tables. If we create a temporary table and retreive date from it using a join with an existing table, only a few of the rows which should have been returned would be returned. In our case this only happened when the temp table was "large". I don't know exactly where it hit, but at a few thousand rows. If we created an index on the temp table that was used for the join it seemed to work better. Our way arround this has been not to use temporary tables joined to regular tables. As this isn't an option for you you might want to check with Informix whether your current version of the engine has a similar error. Nils.Myklebust@ccmail.telemax.no NM-data AS, Toyenbekken 21, Oslo, Norway My opinions are those of my company