[MonetDB-users] monetsql except
i get a weird behavior on sql except. i'm have attached the except.* files from: cat except.sql | mclient -lsql > except.txt notice the tuple: [ 425, 719, "people", "person", NULL ] is returned in all 3 queries; shouldn't except prevent this? any help? i'm runnig on: MonetDB server v5.6.0 (32-bit), based on kernel v1.24.0 (32-bit oids) Copyright (c) 1993-2008 CWI, all rights reserved Visit http://monetdb.cwi.nl/ for further information Configured for prefix: /usr/local Libraries: libpcre: 7.9 2009-04-11 (compiled with 7.9) openssl: OpenSSL 0.9.8k 25 Mar 2009 (compiled with OpenSSL 0.9.8k 25 Mar 2009) Compiled by: root@redrawn Compilation: gcc -O2 -std=c99 Linking : /usr/bin/ld thanx, lazaros. -- http://www.ics.forth.gr/~koromil
forgot the attachments i\m sorry, lazaros. On Wed, Dec 09, 2009 at 02:20:44PM +0200, Lazaros Koromilas wrote:
i get a weird behavior on sql except. i'm have attached the except.* files from: cat except.sql | mclient -lsql > except.txt
notice the tuple: [ 425, 719, "people", "person", NULL ] is returned in all 3 queries; shouldn't except prevent this?
any help?
i'm runnig on: MonetDB server v5.6.0 (32-bit), based on kernel v1.24.0 (32-bit oids) Copyright (c) 1993-2008 CWI, all rights reserved Visit http://monetdb.cwi.nl/ for further information Configured for prefix: /usr/local Libraries: libpcre: 7.9 2009-04-11 (compiled with 7.9) openssl: OpenSSL 0.9.8k 25 Mar 2009 (compiled with OpenSSL 0.9.8k 25 Mar 2009) Compiled by: root@redrawn Compilation: gcc -O2 -std=c99 Linking : /usr/bin/ld
thanx, lazaros.
On 09-12-2009 14:20:44 +0200, Lazaros Koromilas wrote:
i get a weird behavior on sql except. i'm have attached the except.* files from: cat except.sql | mclient -lsql > except.txt
notice the tuple: [ 425, 719, "people", "person", NULL ] is returned in all 3 queries; shouldn't except prevent this?
any help?
i'm runnig on: MonetDB server v5.6.0 (32-bit), based on kernel v1.24.0 (32-bit oids) Copyright (c) 1993-2008 CWI, all rights reserved
Could you try this again with a more recent version? The problem might have been fixed already.
On Wed, Dec 09, 2009 at 01:59:21PM +0100, Fabian Groffen wrote:
On 09-12-2009 14:20:44 +0200, Lazaros Koromilas wrote:
i get a weird behavior on sql except. i'm have attached the except.* files from: cat except.sql | mclient -lsql > except.txt
notice the tuple: [ 425, 719, "people", "person", NULL ] is returned in all 3 queries; shouldn't except prevent this?
any help?
i'm runnig on: MonetDB server v5.6.0 (32-bit), based on kernel v1.24.0 (32-bit oids) Copyright (c) 1993-2008 CWI, all rights reserved
Could you try this again with a more recent version? The problem might have been fixed already.
Lazaros, FYI, the latest release is Nov2009, i.e., MonetDB server v5.16.0, based on kernel v1.34.0; cf., http://monetdb.cwi.nl/Development/Releases/Nov2009/ Stefan -- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |
On Thu, Dec 10, 2009 at 09:47:29AM +0100, Stefan Manegold wrote:
On Wed, Dec 09, 2009 at 01:59:21PM +0100, Fabian Groffen wrote:
On 09-12-2009 14:20:44 +0200, Lazaros Koromilas wrote:
i get a weird behavior on sql except. i'm have attached the except.* files from: cat except.sql | mclient -lsql > except.txt
notice the tuple: [ 425, 719, "people", "person", NULL ] is returned in all 3 queries; shouldn't except prevent this?
any help?
i'm runnig on: MonetDB server v5.6.0 (32-bit), based on kernel v1.24.0 (32-bit oids) Copyright (c) 1993-2008 CWI, all rights reserved
Could you try this again with a more recent version? The problem might have been fixed already.
Lazaros,
FYI, the latest release is Nov2009, i.e., MonetDB server v5.16.0, based on kernel v1.34.0; cf., http://monetdb.cwi.nl/Development/Releases/Nov2009/
Stefan
hello again, i've got the same results with nov2009 release. also, is there any way to get the old cmapi-based python adapter working? (the one with the dictonary cursor) it's considerably faster than the pure-python one. trying from older releases gives me an `incomplete challenge' error. thanx, lazaros. -- http://www.ics.forth.gr/~koromil
participants (3)
-
Fabian Groffen -
Lazaros Koromilas -
Stefan Manegold