Re: ESQL/C vs. SQLDA

steve53@earthlink.net offerred: +I've got an ESQL/C application (Solaris, Informix SE v7.2). There are +cases where I need to rebuild the SELECT statments with the same +fields list but a different query. In an effort to wring out a bit +more performance, I decided that I could avoid the DESCRIBE +overhead and reuse the fields clause SQLDA since the fields list +never changed. This worked well until I discovered that Informix +creates an SQLDA that contains pointers (i.e. sqlname) to data outside +the SQLDA structure allocated by Informix. + +Did I miss something? If so, would someone to point me at the +documentation that says I am required to do a DESCRIBE after +'every' PREPARE? You don't need to do a describe after every prepare. In fact, you don't need to do a describe at all, if you don't want to. You can allocate sqlda structs yourself, if you so desire. The describe is a handy way of getting an sqlda that corresponds to your select statement. If the field list doesn't change, then there is no need to redescribe, as the sqlda struct is still appropriate for your new query. You need to allocate space to receive the data no matter what - DESCRIBE does NOT do any allocation for the data itself, it only allocates the structures. You need to malloc the space and point and point the sqldata pointer to that malloc()ed space. At that point, they are really just somewhat complicated host variables. As long as the sqltype of any element does not change, there is no need to redescribe. In fact, before the current release, there was no way to describe an update statement. To get an sqlda to use with an update, you'd prepare a select * for the table to be updated, and then do a describe on that statement. That would give you an sqlda struct with all the columns from the table. You could then do the update, essentially updating all the columns (but only providing "new" data for the ones you really wanted to update). So the same "described" sqlda was used for the select and the update. Btw, the fields you are worried about (name, primarily) are really there for the use of the program (you'd use the name field as the potential label for the column in some sort of output display). They have no meaning in the context of populating the individual sqlvar structs with data. Dave ** Dave Kosenk <davek@summitdata.com> ** Director of Training Services (732) 469-4070 ** Summit Data Group (an Informix Authorized Education Center) ** Find my advice useful? Let me teach you everything I know about ** Informix. Sign up for OFFICIAL Informix training at SDG. ** For details, see http://www.summitdata.com/training