Bug#354723: Processed: Re: Bug#354723: unixodbc: fails to retrieve data from ODBC connection
Did you try setting believeNRows=FALSE in odbcConnect() ? From help(odbcConnect, package=RODBC): odbcConnect(dsn, uid = , pwd = , case = nochange, believeNRows = TRUE) [...] believeNRows: logical. Is the number of rows returned by the ODBC connection believable? Not true for Oracle and Sybase, apparently. This has been the fix on other systems, it could simply that RODBC gets handed a bad value. Apparently common with some backends, as I recall I had to use that too with some Sybase-on-Solaris versions a while back. Yes, I have tried this with the exact same result. I have to stress that this only happens on ONE of my systems (pure amd64). Probably something really stupid but I just can't get it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354723: Processed: Re: Bug#354723: unixodbc: fails to retrieve data from ODBC connection
On 1 March 2006 at 22:30, Dirk Eddelbuettel wrote: | Did you try setting believeNRows=FALSE in odbcConnect() ? From | help(odbcConnect, package=RODBC): [...] | odbcConnect(dsn, uid = , pwd = , case = nochange, | believeNRows = TRUE) | [...] | believeNRows: logical. Is the number of rows returned by the ODBC | connection believable? Not true for Oracle and Sybase, | apparently. | | This has been the fix on other systems, it could simply that RODBC gets | handed a bad value. Apparently common with some backends, as I recall I had | to use that too with some Sybase-on-Solaris versions a while back. I really meant FALSE, not TRUE: On 2 March 2006 at 10:00, Johannes Ranke wrote: | Package: r-cran-rodbc | Version: 1.1.5-1 | Followup-For: Bug #354723 [...] | [EMAIL PROTECTED]:~$ cat odbctest.R | library(RODBC) | channel - odbcConnect(cytotox,uid=cytotox, | pwd=cytotox, believeNRows=TRUE) ^^ | query - SELECT plate FROM plates LIMIT 1,10 | tables - sqlQuery(channel,query) | tables | odbcGetErrMsg(channel) | odbcClose(channel) So could you please try with FALSE? Otherwise, I agree with a comment you made in the another mail that it is probably the myodbc driver that causes it. RODBC only passes the command on. Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354723: Processed: Re: Bug#354723: unixodbc: fails to retrieve data from ODBC connection
* Dirk Eddelbuettel [EMAIL PROTECTED] [060302 13:30]: On 1 March 2006 at 22:30, Dirk Eddelbuettel wrote: | Did you try setting believeNRows=FALSE in odbcConnect() ? From | help(odbcConnect, package=RODBC): [...] | odbcConnect(dsn, uid = , pwd = , case = nochange, | believeNRows = TRUE) | [...] | believeNRows: logical. Is the number of rows returned by the ODBC | connection believable? Not true for Oracle and Sybase, | apparently. | | This has been the fix on other systems, it could simply that RODBC gets | handed a bad value. Apparently common with some backends, as I recall I had | to use that too with some Sybase-on-Solaris versions a while back. I really meant FALSE, not TRUE: On 2 March 2006 at 10:00, Johannes Ranke wrote: | Package: r-cran-rodbc | Version: 1.1.5-1 | Followup-For: Bug #354723 [...] | [EMAIL PROTECTED]:~$ cat odbctest.R | library(RODBC) | channel - odbcConnect(cytotox,uid=cytotox, | pwd=cytotox, believeNRows=TRUE) ^^ | query - SELECT plate FROM plates LIMIT 1,10 | tables - sqlQuery(channel,query) | tables | odbcGetErrMsg(channel) | odbcClose(channel) So could you please try with FALSE? Hi again, as I said something in the mess above, I DID try with FALSE, here it is library(RODBC) channel - odbcConnect(cytotox,uid=cytotox, + pwd=cytotox, believeNRows=FALSE) query - SELECT plate FROM plates LIMIT 1,10 tables - sqlQuery(channel,query) tables character(0) odbcGetErrMsg(channel) character(0) odbcClose(channel) Otherwise, I agree with a comment you made in the another mail that it is probably the myodbc driver that causes it. RODBC only passes the command on. I could fix the problem of the segfault of php5-odbc by recompiling libmyodbc (I will add this story to #353997, which is the same bug) But on this, I am still working. The following strace comparison between working (i386 box) and failing (amd64 box) might be useful: i386 ... write(1, query - \SELECT plate FROM pl..., 49 query - SELECT plate FROM plates LIMIT 1,10 ) = 49 write(1, tables - sqlQuery(channel,que..., 36 tables - sqlQuery(channel,query) ) = 36 semop(98306, 0xbfd50c90, 2) = 0 semop(98306, 0xbfd50c9e, 1) = 0 time(NULL) = 1141300906 fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 read(3, 0x86086c0, 8192)= -1 EAGAIN (Resource temporarily unavailable) fcntl64(3, F_SETFL, O_RDWR) = 0 write(3, $\0\0\0\3SELECT plate FROM plates LI..., 40) = 40 read(3, \1\0\0\1, 4) = 4 read(3, \1, 1)= 1 read(3, \27\0\0\2, 4) = 4 read(3, \6plates\5plate\3\v\0\0\1\3\3\0\0\0, 23) = 23 read(3, \1\0\0\3, 4) = 4 read(3, \376, 1) = 1 read(3, \2\0\0\4, 4) = 4 read(3, \0014, 2) = 2 read(3, \2\0\0\5, 4) = 4 read(3, \0015, 2) = 2 read(3, \2\0\0\6, 4) = 4 read(3, \0016, 2) = 2 read(3, \2\0\0\7, 4) = 4 read(3, \0018, 2) = 2 ... amd64: ... write(1, query - \SELECT plate FROM pl..., 49 query - SELECT plate FROM plates LIMIT 1,10 ) = 49 write(1, tables - sqlQuery(channel,que..., 36 tables - sqlQuery(channel,query) ) = 36 semop(32769, 0x16d1d08, 140737486958608) = 0 semop(32769, 0x16d1d08, 140737486958608) = 0 fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)= 0 read(3, 0xb508b0, 8192) = -1 EAGAIN (Resource temporarily unavailable) fcntl(3, F_SETFL, O_RDWR) = 0 write(3, $\0\0\0\3SELECT plate FROM plates LI..., 40) = 40 read(3, \1\0\0\1\0013\0\0\2\3def\7cytotox\6plates\6pla..., 16384) = 144 write(1, tables\n, 9 tables ) = 9 write(1, character(0)\n, 13character(0) ) = 13 ... It tells me that mysql returns lots of data, which is not correctly read by whatever reads it. It can't really be myODBC, because I can retrieve the data with isql, as I demonstrated above. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354723: Processed: Re: Bug#354723: unixodbc: fails to retrieve data from ODBC connection
On 2 March 2006 at 13:46, Johannes Ranke wrote: | | * Dirk Eddelbuettel [EMAIL PROTECTED] [060302 13:30]: | | On 1 March 2006 at 22:30, Dirk Eddelbuettel wrote: | | Did you try setting believeNRows=FALSE in odbcConnect() ? From | | help(odbcConnect, package=RODBC): | [...] | | odbcConnect(dsn, uid = , pwd = , case = nochange, | | believeNRows = TRUE) | | [...] | | believeNRows: logical. Is the number of rows returned by the ODBC | | connection believable? Not true for Oracle and Sybase, | | apparently. | | | | This has been the fix on other systems, it could simply that RODBC gets | | handed a bad value. Apparently common with some backends, as I recall I had | | to use that too with some Sybase-on-Solaris versions a while back. | | I really meant FALSE, not TRUE: | | On 2 March 2006 at 10:00, Johannes Ranke wrote: | | Package: r-cran-rodbc | | Version: 1.1.5-1 | | Followup-For: Bug #354723 | [...] | | [EMAIL PROTECTED]:~$ cat odbctest.R | | library(RODBC) | | channel - odbcConnect(cytotox,uid=cytotox, | | pwd=cytotox, believeNRows=TRUE) | ^^ | | query - SELECT plate FROM plates LIMIT 1,10 | | tables - sqlQuery(channel,query) | | tables | | odbcGetErrMsg(channel) | | odbcClose(channel) | | So could you please try with FALSE? | | Hi again, | | as I said something in the mess above, I DID try with FALSE, here it is Sorry, I must have mised that. | | library(RODBC) | channel - odbcConnect(cytotox,uid=cytotox, | + pwd=cytotox, believeNRows=FALSE) | query - SELECT plate FROM plates LIMIT 1,10 | tables - sqlQuery(channel,query) | tables | character(0) | odbcGetErrMsg(channel) | character(0) | odbcClose(channel) I see. | Otherwise, I agree with a comment you made in the another mail that it is | probably the myodbc driver that causes it. RODBC only passes the command on. | | I could fix the problem of the segfault of php5-odbc by recompiling | libmyodbc (I will add this story to #353997, which is the same bug) I am still lost. So is this, or isn't this, one bug report. | But on this, I am still working. The following strace comparison between | working (i386 box) and failing (amd64 box) might be useful: I am not exactly sure how this would help me. I need one reproducable bug report. As you said yourself, RODBC works on all your other platforms, and I never had complaints from any other amd64 user ... so I'd really like something tangible before I go to the upstream maintainer with this. Sorry for all yoru troubles, and thanks for the help. Dirk | i386 | | ... | write(1, query - \SELECT plate FROM pl..., 49 query - SELECT plate FROM plates LIMIT 1,10 | ) = 49 | write(1, tables - sqlQuery(channel,que..., 36 tables - sqlQuery(channel,query) | ) = 36 | semop(98306, 0xbfd50c90, 2) = 0 | semop(98306, 0xbfd50c9e, 1) = 0 | time(NULL) = 1141300906 | fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 | read(3, 0x86086c0, 8192)= -1 EAGAIN (Resource temporarily unavailable) | fcntl64(3, F_SETFL, O_RDWR) = 0 | write(3, $\0\0\0\3SELECT plate FROM plates LI..., 40) = 40 | read(3, \1\0\0\1, 4) = 4 | read(3, \1, 1)= 1 | read(3, \27\0\0\2, 4) = 4 | read(3, \6plates\5plate\3\v\0\0\1\3\3\0\0\0, 23) = 23 | read(3, \1\0\0\3, 4) = 4 | read(3, \376, 1) = 1 | read(3, \2\0\0\4, 4) = 4 | read(3, \0014, 2) = 2 | read(3, \2\0\0\5, 4) = 4 | read(3, \0015, 2) = 2 | read(3, \2\0\0\6, 4) = 4 | read(3, \0016, 2) = 2 | read(3, \2\0\0\7, 4) = 4 | read(3, \0018, 2) = 2 | ... | | amd64: | | ... | write(1, query - \SELECT plate FROM pl..., 49 query - SELECT plate FROM plates LIMIT 1,10 | ) = 49 | write(1, tables - sqlQuery(channel,que..., 36 tables - sqlQuery(channel,query) | ) = 36 | semop(32769, 0x16d1d08, 140737486958608) = 0 | semop(32769, 0x16d1d08, 140737486958608) = 0 | fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)= 0 | read(3, 0xb508b0, 8192) = -1 EAGAIN (Resource temporarily unavailable) | fcntl(3, F_SETFL, O_RDWR) = 0 | write(3, $\0\0\0\3SELECT plate FROM plates LI..., 40) = 40 | read(3, \1\0\0\1\0013\0\0\2\3def\7cytotox\6plates\6pla..., 16384) = 144 | write(1, tables\n, 9 tables | ) = 9 | write(1, character(0)\n, 13character(0) | ) = 13 | | ... | | It tells me that mysql returns lots of data, which is not correctly read | by whatever reads it. It can't really be myODBC, because I can retrieve | the data with isql, as I demonstrated above. -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison -- To UNSUBSCRIBE, email
Bug#354723: Processed: Re: Bug#354723: unixodbc: fails to retrieve data from ODBC connection
| I could fix the problem of the segfault of php5-odbc by recompiling | libmyodbc (I will add this story to #353997, which is the same bug) I am still lost. So is this, or isn't this, one bug report. OK, this wasn't clear. I meant, the problem with php5-odbc is the same as in #353997. The problem with RODBC is not fixed by recompiling libmyodbc, and must therefore have a different reason. | But on this, I am still working. The following strace comparison between | working (i386 box) and failing (amd64 box) might be useful: I am not exactly sure how this would help me. I need one reproducable bug report. ACK. As you said yourself, RODBC works on all your other platforms, and I never had complaints from any other amd64 user ... so I'd really like something tangible before I go to the upstream maintainer with this. Well, it is quite tangible for me, inasmuch as I can't work with RODBC on this machine. I use it a lot. And it used to work before. Unfortunately I can't associate the appearance of the bug with any upgrade. Probably it's something trivial. Maybe the locale settings. I understand you don't want to involve BDR. I will keep on thinking. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354723: Processed: Re: Bug#354723: unixodbc: fails to retrieve data from ODBC connection
I just inherited this bug report. As I understand ODBC, the actual lifting is done by the ODBC driver of the RDBMS -- here MySQL. My casual look seems to indicate that the segfault is there, so neither a r-cran-rodbc bug, nor (as Steve determined) a odbcconfig bug. But why r-cran-rodbc? That package has been very stable upstream, and generally solid. Dirk On 1 March 2006 at 16:18, Debian Bug Tracking System wrote: | Processing commands for [EMAIL PROTECTED]: | | reassign 354723 r-cran-rodbc | Bug#354723: unixodbc: fails to retrieve data from ODBC connection | Bug reassigned from package `unixodbc' to `r-cran-rodbc'. | | thanks | Stopping processing here. | | Please contact me if you need assistance. | | Debian bug tracking system administrator | (administrator, Debian Bugs database) | -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354723: Processed: Re: Bug#354723: unixodbc: fails to retrieve data from ODBC connection
On Wed, Mar 01, 2006 at 09:00:02PM -0600, Dirk Eddelbuettel wrote: I just inherited this bug report. As I understand ODBC, the actual lifting is done by the ODBC driver of the RDBMS -- here MySQL. My casual look seems to indicate that the segfault is there, so neither a r-cran-rodbc bug, nor (as Steve determined) a odbcconfig bug. But why r-cran-rodbc? That package has been very stable upstream, and generally solid. Because the behavior when trying to issue a query using r-cran-rodbc is *not* a segfault, it's simply a failure to return the data, and this behavior was not reproducible with isql. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#354723: Processed: Re: Bug#354723: unixodbc: fails to retrieve data from ODBC connection
On 1 March 2006 at 19:06, Steve Langasek wrote: | On Wed, Mar 01, 2006 at 09:00:02PM -0600, Dirk Eddelbuettel wrote: | | I just inherited this bug report. As I understand ODBC, the actual lifting is | done by the ODBC driver of the RDBMS -- here MySQL. My casual look seems to | indicate that the segfault is there, so neither a r-cran-rodbc bug, nor (as | Steve determined) a odbcconfig bug. | | But why r-cran-rodbc? That package has been very stable upstream, and | generally solid. | | Because the behavior when trying to issue a query using r-cran-rodbc is | *not* a segfault, it's simply a failure to return the data, and this | behavior was not reproducible with isql. Could you point me to a reproducible example? This would help me greatly in bringing this up with upstream. Dirk, swamped as I just did a Quantian release -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354723: Processed: Re: Bug#354723: unixodbc: fails to retrieve data from ODBC connection
Johannes, On 1 March 2006 at 19:06, Steve Langasek wrote: | On Wed, Mar 01, 2006 at 09:00:02PM -0600, Dirk Eddelbuettel wrote: | | I just inherited this bug report. As I understand ODBC, the actual lifting is | done by the ODBC driver of the RDBMS -- here MySQL. My casual look seems to | indicate that the segfault is there, so neither a r-cran-rodbc bug, nor (as | Steve determined) a odbcconfig bug. | | But why r-cran-rodbc? That package has been very stable upstream, and | generally solid. | | Because the behavior when trying to issue a query using r-cran-rodbc is | *not* a segfault, it's simply a failure to return the data, and this | behavior was not reproducible with isql. Did you try setting believeNRows=FALSE in odbcConnect() ? From help(odbcConnect, package=RODBC): odbcConnect(dsn, uid = , pwd = , case = nochange, believeNRows = TRUE) [...] believeNRows: logical. Is the number of rows returned by the ODBC connection believable? Not true for Oracle and Sybase, apparently. This has been the fix on other systems, it could simply that RODBC gets handed a bad value. Apparently common with some backends, as I recall I had to use that too with some Sybase-on-Solaris versions a while back. Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
