Re: ESQL/C dynamic update problem

The DESCRIBE does not give you the details of the parameters of an UPDATE statement. It only ever gives you the description of the output data from the database, which means that only two statements ever have descriptions returned: SELECT and EXECUTE PROCEDURE. And even for these, you do not get a description of the input parameters! Consider: SELECT * FROM SomeTable WHERE SomeColumn IN (SELECT T2.AnotherColumn FROM SomeOtherTable T2 WHERE T2.SomeColumn = ?) If this statement is prepared and described, ESQL/C will give you an sqlda structure with the result of expanding the "*", but it won't contain any description of SomeColumn. Similarly, all the values in the UPDATE statement are input parameters, and you have to know their types ahead of time by some other mechanism than DESCRIBE. Given that this is the correct behaviour, there is no question of reporting bugs or finding fixed versions. If you really need to know what those types are, you can arrange to prepare and describe a SELECT statement which lists the columns in the SELECT-list. This will give you an sqlda structure with the information you require. In my example, I would prepare and describe: SELECT AnotherColumn FROM SomeOtherTable Yours, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h> }From: gmn@geac.co.nz (Greg Nikoloff) }Date: 7 Aug 1995 05:10:35 GMT }X-Informix-List-Id: <news.16044> } }I have some ESQL/C code which performs fully dynamic SQL, and its been }working fine for 3+ years, recently a colleague decided to change his }code [which calls my code to perform the dynamic preparation and }execution etc] from a non-parameterized update to a parameterized update, }i.e. he now says [using the ubiquitous stores database, and table }'orders']: } }'update orders set order_date = ? where order_num = ?' } }instead of [as an example of what he said before]: } }'update orders set order_date = 1995/08/08 where order_num = 1000' } }This is valid SQL, the only problem is that a DESCRIBE of this prepared }statement should return in the first case a sqlda containing 2 }parameters, one is for the new value of order_date, the second is for the }value of order_num to update. }However DESCRIBE (which allocates and fills in SQLDA for me) returns }sqlda->sqld (i.e. number of sqlvar structs in the sqlda) of 0 , } }i.e. the DESCRIBE statement thinks there are NO parameters to be }processed, despite the '?'s in the prepared statement! } }[The SQLCODE returned from the DESCRIBE indicates that the prepare knows }the statement to be an update with a 'where' clause (i.e. SQLCODE = 4 }after the describe). So its not Informix thinking its some other }statement type!]. }[...]