The Oracle database stores data in which the Cyrillic alphabet is present, CHARACTERSET CL8MSWIN1251. I take it through ODBC, instead of Cyrillic - question marks.

std::string kOdbcWrapper::KSQLStatement::getFieldAsString(unsigned short nsColNum) { SQLINTEGER nRlDataSz = 0; const unsigned int nBufSize = 256; char cBuff[nBufSize]={0}; std::string sRetStr; RETCODE rc = SQLGetData(m_hldStmt->getHandle(), nsColNum,SQL_C_CHAR,cBuff,nBufSize,&nRlDataSz); if (rc==SQL_SUCCESS||rc==SQL_SUCCESS_WITH_INFO) { sRetStr = cBuff; return sRetStr; } if (nRlDataSz>0) { SQLINTEGER nVecBufSz = nRlDataSz+1; std::vector<char> vBuff(nVecBufSz, 0); rc = SQLGetData(m_hldStmt->getHandle(), nsColNum, SQL_C_CHAR, reinterpret_cast<SQLCHAR *>(&vBuff.front()), nVecBufSz, &nRlDataSz); if (rc==SQL_SUCCESS||rc==SQL_SUCCESS_WITH_INFO) return std::string(&vBuff[0], vBuff.size()); } return sRetStr; }

    1 answer 1

    The problem originates due to inconsistencies in client and server encodings. Encodings are checked through SELECT * nls_session_parameters and SELECT * nls_database_parameters respectively. It is necessary to check the presence of the NLS_LANG environment NLS_LANG on the client, and in case of its absence set it. In my case, the base was encoded in AMERICAN_AMERICA.CL8MSWIN1251 setting the same encoding in the NLS_LANG problem gone