Comment 3 for bug 1412955

Did some testing regarding 8605.
We used the odbc atomics program in gdb step mode to see when the mxosvrs were generating the 8605 errors in the master_exec_#_pid.log files.

1- When the odbc program calls
    retcode = SQLConnect(hdbc,(unsigned char *)dsnName,SQL_NTS,(unsigned char *)user,SQL_NTS,(unsigned char *)password,SQL_NTS);
and it is the first ever connection to a particular mxosrvr, it logs an 8506 error. Retcode is 0 in the client program. IE: No errors.
2- The odbc program then sets AUTOCOMMIT OFF.
Later on it does the following:
      sprintf( (char *)sqlStmt, "SELECT MAX(cnt) FROM %s", hv_tablename );
  if (alloc_hstmt()) exit( retcode );
  if (!SQL_SUCCEEDED((retcode = SQLExecDirect(hstmt,sqlStmt,SQL_NTS)))) {….}
  if (!SQL_SUCCEEDED((retcode = SQLBindCol(hstmt,1,SQL_C_SLONG,&tempval,sizeof(tempval),&tempind)))) {…}
  if ((retcode = SQLFetch(hstmt)) == SQL_NO_DATA_FOUND) {…}
      if (!SQL_SUCCEEDED((retcode = SQLEndTran(SQL_HANDLE_DBC,hdbc,SQL_COMMIT)))) {…}
At this point another 8605 message is logged in the master_exec_#_pid.log file. retcode is 0 in the client program. IE: No errors.