Re: Help with Informix ESQL/C

It is unfortunate that you regard the 's1 = string1->v_charp' example as unacceptable, because that is the one which the ESQL/C compiler really thinks is acceptable -- and its vote counts more than yours does:-) Of course, hard coding the values in the form is neither desirable nor necessary. You should probably be passing the field name as the string to the called function, and then use the pf_getval() and pf_gettype() routines to retrieve the values from the field named. You ask: And where are these documented? And then we run into some major quirks of Informix history. The answer is the 4.0 ESQL/C Manual. Once upon a time, you only got the ability to use custom Perform when you bought ESQL/C, so the documentation of pf_getval() and friends was in the ESQL/C manual, quite reasonably. Then ISQL and ESQL/C were changed so you got the ability to produce custom Perform when you bought ISQL, though if you called ESQL/C code you still needed the ESQL/C compiler, of course. This was good, except that the documentation did not catch up. The switch happened at version 4.00; the documentation caught up with the 6.0x release of ISQL. So, you either need the 4.00 ESQL/C Manual or the 6.0x ISQL Reference manual -- distinguishing carefully between the Informix-SQL Reference Manual (which you do want) and the Informix Guide to SQL: Reference manual (which won't help you at all). Check in the 4.10 Informix-SQL Supplement -- the documentation may just be in there, though that document is about as common as hen's teeth. I don't have a copy, so I can't check for you. In the interim, the functions prototypes are: int pf_gettype(char *tagname, short *type, short *len); int pf_getval(char *tagname, void *retvalue, int valtype, int vallen); int pf_putval(void *pvalue, int valtype, char *tagname); int pf_nxfield(char *tagname); int pf_msg(char *msgstr, int reverseflag, int bellflag); When you get the manual, you'll find that the 'void *' types are documented as 'char *', though ''void *' is more nearly correct in meaning -- the implementation uses 'char *', but that's a hangover from the days before 'void *' was a type. And the int values are documented as 'short', but only in the non-prototyped form of the functions. The implementation does not use prototypes, and since short values are widened in the absence of a prototype, the prototypes given above are correct. (If you don't understand, you aren't qualified to argue.) The 'void *' values should be a pointer to 'int' or 'long' or 'char *' or whatever type the variable you are trying to load from/to has. The actual type need not match the field type, though it had better be convertible. The functions return 0 on success, and a negative error number on failure. Use pf_gettype() to determine the actual type of a field. Note that the ctools.h header must be used, and you really do need the manual. Yours, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h> >From: jkharris@utk.edu >Date: 4 Dec 1995 20:39:20 GMT >X-Informix-List-Id: <news.19440> > >I am upgrading from Informix ver 3.3 to ver 4.1. I am to the point of >modifying my C code to match the ver 4.1 syntax. I am passing two >parameters from a Perform screen to the C program. It looks something >like: > > call funct1(string1, string2) > >where string1 and string2 are field identifiers for table1 in >the Perform screen. > >The C function is supposed to update the database using these two >strings something like: > > $ update table2 > set field1 = string1 > where field2 = string2;> >I got sqlca.sqlcode = -217, column name not found in any table in >the query. I tried many options. The only way I can get it to update >is to hard code the string values in Perform: > > call funct1("D-99999", "T-3446") > >and change the C code to look like: > > $ char *s1, *s2;> > s1 = string1->v_charp; > s2 = string2->v_charp; > > $ update table2 > set field1 = $s1 > where field2 = $s2;> >or hard code the values in the C program: > > $ update table2 > set field1 = "D-99999" > where field2 = "T-3446";> >Obviously, these solutions are not acceptable. I cannot find an >example in any of the manuals that does a similar operation. I would >greatly appreciate any input. > >jkharris@utk.edu