| Bug #607 | SQLFetch not working with MySQL 4.0.12 - MyODBC 3.51.06 | ||
|---|---|---|---|
| Submitted: | 6 Jun 2003 7:09 | Modified: | 17 Jul 2003 22:58 |
| Reporter: | Gemma Burman | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | Connector / ODBC | Severity: | S1 (Critical) |
| Version: | MyODBC 3.51.06 | OS: | HP/UX (HPUX 10.20) |
| Assigned to: | Venu Anuganti | CPU Architecture: | Any |
[18 Jun 2003 12:26]
Venu Anuganti
Hi !! I am currently testing this, a quick test from Linix worked fine. And let me try this on your specific platform. Thanks Venu
[18 Jun 2003 13:32]
Venu Anuganti
Hi !!! I tested this on HP-UX with a running 4.0.12 server, with Connector/ODBC 3.51.06 binaries that are shipped for 11.0, and it just worked out well. Couple of questions. 1. Did you built the driver by yourself ? If yes, whats the client headers and libraries. 2. What is the libmysqlclient version that libmyodbc3.so is talking to when you saw that last_insert_id() is not working? 'ldd libmyodbc3.so' should reveal this. In case if its talking to 4.0 libmysqlclient, then can you re-direct that to 3.23 client library(Just change the LIBPATH correctly) and see if it returns LAST_INSERT_ID() correctly for running 4.0 server (i.e. driver is linking with 3.23 client and server is 4.0). Thanks Venu
[18 Jun 2003 22:37]
Goutham S Mohan
Following up on the defect #607.... We are trying this with the libmyodbc3.a static library. The problem is being faced in the following scenario: Our client is linked statically to the libmyodbc3.a and the libmysqlclient.a provided with MyODBC 3.51.06 and MySQL 4.0.12 shipped for HPUX 10.20 on a HPUX 11.00 box. We are taking the binaries that are shipped by MySQL AB and we are not building it locally. We did not find a MySQL / MyODBC binary shipped for HPUX 11.00. If this is available, can you kindly give us the link from where this can be obtained. When we tried linking the MyODBC 3.51.06 libmyodbc3.a along with MySQL 3.23.56 version of libmysqlclient.a, it worked fine with no change in our code.
[18 Jun 2003 22:57]
Venu Anuganti
Hi !! You should be able to find the Connector/ODBC and MySQL binaries for HPUX-11 from here: Connector/ODBC 3.51.06: http://www.mysql.com/downloads/api-myodbc-3.51.html MySQL 4.0.13 http://www.mysql.com/downloads/mysql-4.0.html MySQL 3.23.56 http://www.mysql.com/downloads/mysql-3.23.html MySQL 4.1.0 http://www.mysql.com/downloads/mysql-4.1.html Thanks Venu
[19 Jun 2003 2:05]
Goutham S Mohan
We can see only binaries for HPUX 10.20 and HPUX 11.11 and nothing seperately for HPUX 11.00 When we tried to use the HPUX 11.11 binaries we hit upon a linker error - Unresolved symbol “__sendpath64”. I think we need a MyODBC/MySQL build for HPUX 11.00 specifically.
[19 Jun 2003 5:40]
MySQL Verification Team
Can you provide us the access to 11.00 HP-UX, so that we can build binaries on that version ??
[29 Jun 2003 22:33]
[ name withheld ]
Hi, I am testing the same with AIX 4.3 and found the same issue. I have applied the MyODBC 3.51.06 patches which venu has supplied for AIX. We have used MySQL 4.0.12 standard version for AIX. The same behaviour is observed with SQLFetch as in HPUX 11.0. Regards, Thanigai
[30 Jun 2003 0:34]
Venu Anuganti
Hi !! Apart from your sample provided to reproduce the behavior, I also tested with std iodbc and unixODBC tools like 'odbctest' and 'isql' to cross check this LAST_INSERT_ID() issue (SQLFetch) and it just worked fine. Here is the test output from unixODBC 'isql', by talking through Connector/ODBC 3.51.06 and the server is 4.0.13: mysqldev@hpux11:~/venu/local/unixODBC/bin> isql -v myodbc3r venu venu +---------------------------------------+ | Connected! | | | | sql-statement | | help [tablename] | | quit | | | +---------------------------------------+ SQL> select version(); +-----------------+ | version() | +-----------------+ | 4.0.14-debug-log| +-----------------+ 1 rows returned SQL> insert into TEST values(); 1 rows affected SQL> select last_insert_id(); +----------------------+ | last_insert_id() | +----------------------+ | 3 | +----------------------+ 1 rows returned SQL> You can see that it works as expected and this is what happens even in your db_test.c sample. I could able to see that SQLFetch() is working fine on both AIX-43 and HPUX-11 for last_insert_id for all 3 versions of MySQL (3.23.56, 4.0.13 and 4.1.1). So, looks like there is something is wrong from your setup environment. Can you please let me know your ldd output of driver. Thanks Venu
[8 Jul 2003 0:36]
Venu Anuganti
Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.mysql.com/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to 'Open'. Thank you for your interest in MySQL.
Description: Reference :- Kerry Ancheta We are using MySQL 4.0.12 and MyODBC 3.51.06. We are using HPUX-10.20 binaries on a HPUX-11.00 box. ( because MySQL does not ship binaries for HPUX 11.00) SQLFetch does not return any data when a select statement is executed on a table with data. The return code of SQLFetch is always SQL_NO_DATA_FOUND. How to repeat: 1. Create a table using. create table test { id INT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT, name CHAR(64) NOT NULL } TYPE=InnoDB; 2. Through my ODBC client program open a connection with MySQL server. -> Insert a record into the table "test". -> Below is the code to do a select last_insert_id(): (Note: Ignore program variable db - used to store the db handles.) Boolean select_from_db(DbHandle db, unsigned long *maxId) { RETCODE rc; HSTMT hstmt; UCHAR stmtStr[DB_STMT_BUFFER_SIZE]; DbHandleOdbc *handle = (DbHandleOdbc *) db; Boolean success=true; SDWORD valMaxId; /* Initialize maxId */ *maxId = 0; /* Build the SQL statement */ sprintf(stmtStr, "SELECT last_insert_id()"); /* Allocate ODBC statement structure */ rc = SQLAllocStmt( handle->hdbc, &hstmt ); if ( (rc != SQL_SUCCESS) && (rc != SQL_SUCCESS_WITH_INFO) ) { db_odbc_error( handle->henv, handle->hdbc, hstmt, (iString) NULL ); return false; } /* Bind return value */ rc = SQLBindCol( hstmt, 1, SQL_C_ULONG, maxId, sizeof(unsigned long), &valMaxId); /* Execute statement */ rc = SQLExecDirect( hstmt, stmtStr, SQL_NTS ); if ( (rc != SQL_SUCCESS) && (rc != SQL_SUCCESS_WITH_INFO) ) { db_odbc_error (handle->henv, handle->hdbc, hstmt, stmtStr ); rc = SQLFreeStmt( hstmt, SQL_DROP ); return false; } /* Get return value */ rc = SQLFetch( hstmt ); if ( rc == SQL_NO_DATA_FOUND ) /* No max ID found; set to 0 */ *maxId = 0; if ( (rc != SQL_SUCCESS) && (rc != SQL_SUCCESS_WITH_INFO) && (rc != SQL_NO_DATA_FOUND) ) { db_odbc_error( handle->henv, handle->hdbc, hstmt, (iString) NULL ); success = false; } rc = SQLFreeStmt( hstmt, SQL_DROP ); return success; } Note:- 1) With the above piece of code everything goes fine till we reach SQLFetch. But everytime "rc" matches SQL_N0_DATA_FOUND. Record was inserted into the table just before calling the above function. This is not just a case with last_insert_id - This is just an example. The same problem is noticed when we do a "select * from test" with appropriate Bind statements with data populated. 2) The same code works with MySQL 3.23.56 (MAX) with MyODBC 3.51.06