Re: ESQL C problem with sqlerrd[2]

In article <brownlow.724615082@xanadu> brownlow@informix.com (Keith Brownlow) writes: >>The sqlca.sqlerrd[2] value DOES NOT hold the number of rows found by opening >>a cursor for a select statement (dynamic or otherwise). The sqlerrd[2] value >>is filled in only by the update and delete statements (maybe insert too), but >>not by a select. > >>The only way to get the number of rows from a select statment is to >>execute some type of "select count(*) into $cnt ..." statement with the same >>from and where clause as the original select statement. > > >A little clarification at this point; > > sqlca.sqlerrd[2] holds the values of the last SERIAL value inserted. Nope. The question was pertaining to ESQL/C, in which case sqlerrd[1] (in C, the second occurrence in the sqlerrd integer array) is used to hold the last SERIAL returned if the last SQL statement was a successful INSERT. Otherwise, it holds the ISAM/RSAM or O/S error code underlying an Informix error code (if any). sqlerrd[2] is reserved for row counts, for those situations where a row count is provided. >sqlca.sqlerrd[3] will hold the TRUE number of updates and deletes but only >the first of an insert or select. This is because both insert and select >statements need cursors if they are to manipulate more than one row at a time, >while update or deletes will affect every row in the table unless some >criteria is specified. Nope. sqlerrd[2] is what you are after... and the rest of what you said implies that it will always be =1 for a SELECT, which I don't think is true. The INSERT statement itself doesn't work with an INSERT cursor -- to add to an open INSERT cursor, you use PUT, not INSERT. >Hope this clears up any misunderstanding. I think it caused more. [-: -- Alan Denney aland@informix.com {pyramid|uunet}!infmx!aland "People burn more calories while sleeping than while bowling." - Rush Limbaugh, 12/17/92