Whats wrong in this code using ODBC interface of T10 in C ?

Question

Hi!
I am trying to connect TimesTen using ODBC in a C application, I am trying to use the dynamic binding of parameters the query. The problem is elaborated in the code. In the comments.
#include <windows.h>
#include <sql.h>
#include <sqlext.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
int main()
SQLRETURN rc = SQL_SUCCESS;
/* General return code for the API */
SQLHENV hEnv = SQL_NULL_HENV;
/* Environment handle */
SQLHDBC hDbc = SQL_NULL_HDBC;
/* Connection handle */
SQLHSTMT hStmt = SQL_NULL_HSTMT;
/* Statement handle */
SQLCHAR ConnOut[255];
/* Buffer for completed connection string */
SQLSMALLINT connOutLen;
/* number of bytes returned in ConnOut */
SQLCHAR ConnString = (SQLCHAR ) "DSN=testTT;PWD=spideradm;";
/* Connection attributes */
rc = SQLAllocEnv(&hEnv);
if (rc != SQL_SUCCESS) {
fprintf(stderr,"Unable to allocate an environment handle\n");
exit(1);
SQLINTEGER param1 = 0;
SQLINTEGER paramstatus = 0;
rc = SQLAllocConnect(hEnv, &hDbc);
rc = SQLDriverConnect(hDbc, NULL,ConnString, SQL_NTS,ConnOut, 255,&connOutLen,SQL_DRIVER_NOPROMPT);
hStmt = SQL_NULL_HSTMT;
rc = SQLAllocStmt(hDbc, &hStmt);
rc = SQLPrepare(hStmt,(SQLCHAR*) "select * from test where recno = ? ",SQL_NTS);
rc = SQLBindParameter(hStmt,1,SQL_PARAM_INPUT,SQL_C_SHORT,SQL_INTEGER,0,0,¶m1,0,¶mstatus);
param1= 1;
rc = SQLExecute(hStmt); // here it goes very perfect
param1 = 2;
rc = SQLExecute(hStmt); // here is the problem it returns -1
}

Answer 1

There are (at least) 3 problems with this code:
1. The error checking after each ODBC call is far too simplistic. Whenever an ODBC call returns something other than SQL_SUCCESS then you need to call the SQLError() function (multiple times in a loop until it returns SQL_NO_DATA) to retrieve the error or warning information which you should then report. If you do that then the error information would give you a clue to the problem.
2. The parameter variable 'param1' is declared as a SQLINTEGER (32-bit integer) but you bind it in the SQLBindParameter() call as a SQL_C_SHORT. This is incorrect and will likely cause problems. It should be bound as a SQL_C_SLONG.
3. When you execute a statement that retrieves data (such as the SELECT statement in your example) a cursor is created. The cursor remains open until (a) you explicitly close it with SQLFreeStmt(hStmt, SQL_CLOSE), or (b) you do a commit or rollback (which closes all open cursors on the connection).
Your problem here is that the first SQLExecute opens a cursor for hStmt but you then do not fetch any data or close the cursor. When you try the second execute you get an error as there is already an open cursor for that statement. If you had used SQLError(0 to retrieve and report the error codes and messages you would see that you had incurred either an 'INVALID CURSOR STATE' or 'FUNCTION SEQUENCE ERROR' error.
The fix is to insert the call:
SQLFreeStmt(hStmt,SQL_CLOSE);
after the each SQLExecute(0 call. Of course, in a real application there would also be a SQLFetch() loop first to retrieve and process the results of the query.
Chris