Re: comments on ESQL/C dynamic update problem reply

John, thanks for the prompt reply, I have some comments on your comments. >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! Sorry to contradict you John, BUT, if I prepare a dynamic SQL statement such as 'insert into orders (order_date) values (?)' and then DESCRIBE it, Informix quite correctly builds me a sqlda which has a single parameter required, whose data type and length etc [and name!] will match those of the field(s) being inserted (in this case a DATE data type called 'order_date'!). It is my understanding that the DESCRIBE statement gives information about both INPUT & OUTPUT parameters required by the prepared statement, and as the INSERT statement most definately takes only input parameters your assertion about describe only supporting output fields is quite incorrect. Your example was a complicated one because you are supplying both input AND output parameters in the prepared statement, the input parameters are required when the 'OPEN' statement is executed, the output parameters when the 'FETCH' is executed, in that case I too would expect Informix to only give the output parameters since there is no way I know to support both input and output paramters in the same sqlda at the same time. I have no problems if Informix now qualify themselves by saying 'you cannot issue dynamic update statements and expect the DESCRIBE statement to correctly describe the fields being updated' however it begs the question as to why dynamic inserts can be described yet dynamic updates cannot! But lets acknowledge it as a shortcoming/bug not a design 'feature' since I have not read of this limitation anywhere else in any Informix manuals. TO be fair thought while it is not explicitly stated as a supported operation is not explicityly stated as not-supported either, and my past experience has been that the ESQL/C manuals often fail to mention all the possible things you can do, so ommitting to say it is supported/allowed in the manuals is not the same as saying 'its not allowed/ supported'! [and this is especially a problem since my application code did not create the SQL being prepared or described so it has no way of knowing the data types (or column names etc), so it cannot easily do a dummy 'select' to create a valid sqlda, and in any case, even if the 'select' ... method worked, I would find it difficult to be able to include in this query the fields used in the where clause of the update statement (e.g. what kind of select would you do to create a sqlda via select that allows this update statement: 'update orders set order_date = ? where order_num = ? and order_date = ?' especially since its not allowabale to mention a column twice in a select statement (so select order_date,order_num,order_date from orders is not a valid option here, sure we could alias the column but I am sure that there are update statements with where clauses that would be impossible to create a valid select statement for). > >Given that this is the correct behaviour, there is no question of > reporting >bugs or finding fixed versions. I hope that perhaps Informix could (a) clarify the situation and (b) consider allowing updates to be described fully as inserts are rather than just saying 'thats how it is' especially as other RDBMS products do not appear to have this same limitation. >Yours, >Jonathan Leffler (johnl@informix.com) #include <disclaimer.h> Regards Greg Nikoloff