Thread: SQLPutData bug ?
Your name : Mika Mäntylä Your email address : mmantyla@soberit.hut.fi System Configuration --------------------- Architecture (example: Intel Pentium) : AMD Athlon Operating System (example: Linux 2.0.26 ELF) : RH 7.1 PostgreSQL version (example: PostgreSQL-7.1.3): PostgreSQL-7.1.3 Compiler used (example: gcc 2.95.2) : gcc-2.96-97.1 (Used pre-build binaries) FULL description of your problem: ------------------------------------------------ We have ODBC application that is currently running on top of commercial Solid and Sybase databases.With some fixes I got this application to also work on PSQL on top of W2K. Now I'm trying to get the app to work in Linux with libiodbc-3.0.5-1 and postgresql-odbc-7.1.3 However there seems to be problem with SQLPutData call. This was already a problem in W2k with PSQL (ODBC 07_01_0006), and you can see the ugly fix I made in the code. In Linux the same fix causes the program to get segmentation fault in st.ParamData call. If I remove the fix the final st.PutData call in the loop fails. I think this could be problem related to odbc somehow, but I really don't know. ------------------------------------------------------- /**** Code with the problem ************************** else { char buf[256]; int got; pos = 0; do { // This copies data to buffer buf nothing more got = data->GetData( pos, buf, sizeof(buf) ); #ifdef PSQL #ifdef WIN32 if (got == 0) break; #endif //WIN32 #endif //PSQL st.PutData( buf, got ); pos += got; } while( got > 0 ); } rc = st.ParamData( &pos ); ----------------------------------------------------- /**** PutData call ************************/ void DBStmt::PutData( void *buf, int bufsize ) { t_usec = 0; do { rc = SQLPutData( hstmt, buf, bufsize ); } while( rc==SQL_STILL_EXECUTING && SocketOK() ); if( rc!=SQL_SUCCESS ) throw SQLExc( "SQLPutData failed", rc, hdbc, hstmt ); } ----------------------------------------------------- /**** ParamData call ************************/ int DBStmt::ParamData( long *val ) { t_usec = 0; do { rc = SQLParamData( hstmt, (void**)&val ); } while( rc==SQL_STILL_EXECUTING && SocketOK() ); if( rc!=SQL_SUCCESS && rc!=SQL_NEED_DATA ) throw SQLExc( "SQLParamData failed", rc, hdbc, hstmt ); return rc; } -- Mika Mäntylä || SoberIT 09-451 6001 || Spektri Kvartti 3330a
Mika Mantyla wrote: > > Your name : Mika M$BgO(Btyl$Bgî(B > Your email address : mmantyla@soberit.hut.fi > > System Configuration > --------------------- > Architecture (example: Intel Pentium) : AMD Athlon > > Operating System (example: Linux 2.0.26 ELF) : RH 7.1 > > PostgreSQL version (example: PostgreSQL-7.1.3): PostgreSQL-7.1.3 > > Compiler used (example: gcc 2.95.2) : gcc-2.96-97.1 (Used > pre-build binaries) > > FULL description of your problem: > ------------------------------------------------ > We have ODBC application that is currently running on top of commercial > Solid and Sybase databases.With some fixes I got this application to > also work on PSQL on top of W2K. Now I'm trying to get the app to work > in Linux with libiodbc-3.0.5-1 and postgresql-odbc-7.1.3 > > However there seems to be problem with SQLPutData call. This was already > a problem in W2k with PSQL (ODBC 07_01_0006), and you can see the ugly > fix I made in the code. In Linux the same fix causes the program to get > segmentation fault in st.ParamData call. If I remove the fix the final > st.PutData call in the loop fails. > > I think this could be problem related to odbc somehow, but I really > don't know. > > ------------------------------------------------------- > /**** Code with the problem ************************** > else > { > char buf[256]; > int got; > pos = 0; > do > { > // This copies data to buffer buf nothing more > got = data->GetData( pos, buf, sizeof(buf) ); > > #ifdef PSQL > #ifdef WIN32 > if (got == 0) > break; > #endif //WIN32 > #endif //PSQL I don't think it's preferable to call SQLPutData with length 0 for any dbms. Why is the #ifdef needed ? > > st.PutData( buf, got ); > pos += got; > } while( got > 0 ); > } > rc = st.ParamData( &pos ); > > ----------------------------------------------------- > /**** PutData call ************************/ > void > DBStmt::PutData( void *buf, int bufsize ) > { > t_usec = 0; > do > { > rc = SQLPutData( hstmt, buf, bufsize ); > } while( rc==SQL_STILL_EXECUTING && SocketOK() ); > > if( rc!=SQL_SUCCESS ) > throw SQLExc( "SQLPutData failed", rc, hdbc, hstmt ); > } > ----------------------------------------------------- > /**** ParamData call ************************/ > int > DBStmt::ParamData( long *val ) > { > t_usec = 0; > do > { > rc = SQLParamData( hstmt, (void**)&val ); Why &val not val ? regards, Hiroshi Inoue
Hiroshi Inoue wrote: > Mika Mantyla wrote: > >>Your name : Mika Ma"ntyla" >> > >>Your email address : mmantyla@soberit.hut.fi >> >>System Configuration >>--------------------- >> Architecture (example: Intel Pentium) : AMD Athlon >> >> Operating System (example: Linux 2.0.26 ELF) : RH 7.1 >> >> PostgreSQL version (example: PostgreSQL-7.1.3): PostgreSQL-7.1.3 >> >> Compiler used (example: gcc 2.95.2) : gcc-2.96-97.1 (Used >>pre-build binaries) >> >>FULL description of your problem: >>------------------------------------------------ >>We have ODBC application that is currently running on top of commercial >>Solid and Sybase databases.With some fixes I got this application to >>also work on PSQL on top of W2K. Now I'm trying to get the app to work >>in Linux with libiodbc-3.0.5-1 and postgresql-odbc-7.1.3 >> >>However there seems to be problem with SQLPutData call. This was already >>a problem in W2k with PSQL (ODBC 07_01_0006), and you can see the ugly >>fix I made in the code. In Linux the same fix causes the program to get >>segmentation fault in st.ParamData call. If I remove the fix the final >>st.PutData call in the loop fails. >> >>I think this could be problem related to odbc somehow, but I really >>don't know. >> >>------------------------------------------------------- >>/**** Code with the problem ************************** >> else >> { >> char buf[256]; >> int got; >> pos = 0; >> do >> { >> // This copies data to buffer buf nothing more >> got = data->GetData( pos, buf, sizeof(buf) ); >> >>#ifdef PSQL >>#ifdef WIN32 >> if (got == 0) >> break; >>#endif //WIN32 >>#endif //PSQL >> > > I don't think it's preferable to call SQLPutData with length 0 > for any dbms. Why is the #ifdef needed ? If I remove the #ifdef, I sometimes get segmentation fault from st.ParamData(&pos) which calls SQLParamData. This segmentation fault from SQLParamData only comes with large values of variable pos e.g 358228. So it actually could be a problem with the SQLParamData and large values. > > >> st.PutData( buf, got ); >> pos += got; >> } while( got > 0 ); >> } >> rc = st.ParamData( &pos ); >> >>----------------------------------------------------- >>/**** PutData call ************************/ >>void >>DBStmt::PutData( void *buf, int bufsize ) >>{ >> t_usec = 0; >> do >> { >> rc = SQLPutData( hstmt, buf, bufsize ); >> } while( rc==SQL_STILL_EXECUTING && SocketOK() ); >> >> if( rc!=SQL_SUCCESS ) >> throw SQLExc( "SQLPutData failed", rc, hdbc, hstmt ); >>} >>----------------------------------------------------- >>/**** ParamData call ************************/ >>int >>DBStmt::ParamData( long *val ) >>{ >> t_usec = 0; >> do >> { >> rc = SQLParamData( hstmt, (void**)&val ); >> > > Why &val not val ? Pointer to pointer. Tried chaning that, and it really broke to hole application down. -- Mika Ma"ntyla" || SoberIT 09-451 6001 || Spektri Kvartti 3330a
Mika Mantyla wrote: > > Hiroshi Inoue wrote: > > > Mika Mantyla wrote: > > > >>Your name : Mika Ma"ntyla" > >> > > > >>Your email address : mmantyla@soberit.hut.fi > >> > >>System Configuration > >>--------------------- > >> Architecture (example: Intel Pentium) : AMD Athlon > >> > >> Operating System (example: Linux 2.0.26 ELF) : RH 7.1 > >> > >> PostgreSQL version (example: PostgreSQL-7.1.3): PostgreSQL-7.1.3 > >> > >> Compiler used (example: gcc 2.95.2) : gcc-2.96-97.1 (Used > >>pre-build binaries) > >> > >>FULL description of your problem: > >>------------------------------------------------ > >>We have ODBC application that is currently running on top of commercial > >>Solid and Sybase databases.With some fixes I got this application to > >>also work on PSQL on top of W2K. Now I'm trying to get the app to work > >>in Linux with libiodbc-3.0.5-1 and postgresql-odbc-7.1.3 Hmm the psqlodbc driver seems old. On unix there's no binary distribution of psqlodbc driver like Windows. Maybe you have to compile the driver from the PG snapshot by yourself. regards, Hiroshi Inoue