Hi, Just trying to make the problem a little clearer. I am writing a database provider that provides an interface to the ODBC driver of SAP. All Queries are executed by a third party program through the data base provider using prepared statements. i.e. I have no prior knowledge of the query. The third party program needs an updateable cursor. It primarily executes two types of query 1>"Select count(*) from xxxx where xxxx=xxxx" 2>"Select * from xxxx where xxxx=xxxx for update of" Currently SQL_CONCUR_LOCK is set for both types of queries but causes a problem with 1 (i.e. table is not updateable).I do not know if the same problem occurs for 2.I assume that the program needs updateable cursors only for 2. I use the ODBC driver in oracle mode. All tables are of the structure (Column1 LONG RAW, column2 varchar(10)) <--the PK
**************************************************************************** My question is: So must I parse/check each incoming query and set the CONCUR_LOCK only for type 2. Will updateable cursors work for type 2? Will the ODBC driver add an extra "for update of" to queries of type 2? (Like it did for type 1) Are there any known issues for columns containing 'RAW' data and SAPDB ODBC? What do I set the isolation level to in the SAP DB ODBC window?(in ODBC sources control panel.) Hope someone can clarify. **************************************************************************** Note: The original database provider source that I am forced to modify is known to work with ORACLE/DB2/SYBASE ODBC drivers. It initially didn't work with sap DB ODBC due to the NULL terminator inclusive string length problem. Now always setting Updateable Cursors for all prepared statements seem to be the problem. Regards, Ajit _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
