RE: Bug in BETWEEN same DATETIME

t; Sent: Friday, May 24, 2013 11:08 AM > To: mysql@lists.mysql.com > Subject: Re: Bug in BETWEEN same DATETIME > > >>>> 2013/05/24 09:49 -0400, shawn green >>>> > Or we could coerce datetime values back to their date values when both > are being used. The

Re: Bug in BETWEEN same DATETIME

2013/05/24 09:49 -0400, shawn green Or we could coerce datetime values back to their date values when both are being used. The trick now becomes choosing between rounding the datetime value (times past noon round to the next date) or do we use the floor() function all the time. <<<

Re: Bug in BETWEEN same DATETIME

Hi Rick, Thank you for continuing this. It brings up a few good points. On 5/24/2013 12:17 PM, Rick James wrote: For years (even decades), I have stayed out of trouble by assuming a 'date' represents the instant in time corresponding to midnight at the start of that day. In MySQL (until 5.6)

RE: Bug in BETWEEN same DATETIME

g event, an appointment (potentially in a diff timezone), train schedule, etc. > -Original Message- > From: shawn green [mailto:shawn.l.gr...@oracle.com] > Sent: Friday, May 24, 2013 6:50 AM > To: mysql@lists.mysql.com > Subject: Re: Bug in BETWEEN same DATETIME > >

Re: Bug in BETWEEN same DATETIME

Hello Rick, On 5/23/2013 7:08 PM, Rick James wrote: Watch out for CAST(), DATE(), and any other function. In a WHERE clause, if you hide an indexed column inside a function, the index cannot be used for optimization. INDEX(datetime_col) ... WHERE DATE(datetime_col) = '2013-01-01' wi

Re: Bug in BETWEEN same DATETIME

Personally I don't share your view that it's a bug. Omitting the time results in midnight by default so this screws between because there's no time between 00:00:00 and 00:00:00. Are you having operational issues here or are you simply fishing for bugs? WHERE `transaction_date` = DATE(datetime)

RE: Bug in BETWEEN same DATETIME

You probably want where cast(transaction_date as date) BETWEEN '2013-04-16' AND '2013-04-16' That works on my test case You could also change the where clause to be >= date and < date+1 -Original Message- From: Daevid Vincent [mailto:dae...@daevid.com] Sent: Thursday, May 23, 2

Re: Bug in BETWEEN same DATETIME

>> where cast(transaction_date as date) BETWEEN '2013-04-16' AND This approach might be problematic in that it requires that every row in the source table be examined so that it's transaction_date can be casted. The original formulation is more efficient as it allows an index on transactio

Re: Bug in BETWEEN same DATETIME

On 5/23/2013 4:55 PM, Daevid Vincent wrote: I just noticed what I consider to be a bug; and related, has this been fixed in later versions of MySQL? We are using: mysql Ver 14.12 Distrib 5.0.92, for portbld-freebsd8.1 (amd64) using 5.2 If you use BETWEEN and the same date for both parts (i.

RE: Bug in BETWEEN same DATETIME

iginal Message- > From: shawn green [mailto:shawn.l.gr...@oracle.com] > Sent: Thursday, May 23, 2013 3:50 PM > To: mysql@lists.mysql.com > Subject: Re: Bug in BETWEEN same DATETIME > > > > On 5/23/2013 4:55 PM, Daevid Vincent wrote: > > I just noticed what I

RE: Bug in BETWEEN same DATETIME

he same starting date. > -Original Message- > From: Michael Dykman [mailto:mdyk...@gmail.com] > Sent: Thursday, May 23, 2013 2:56 PM > To: MySql > Subject: Re: Bug in BETWEEN same DATETIME > > >> where cast(transaction_date as date) BETWEEN '2013-04-16&#x

Re: Bug in BETWEEN same DATETIME

Sorry, that was meant to be; WHERE (new column stored as date) = '2013-04-16' On Thu, May 23, 2013 at 10:16 PM, Andrew Moore wrote: > Personally I don't share your view that it's a bug. Omitting the time > results in midnight by default so this screws between because there's no > time between

Re: Bug using 32-bit libmysqlclient on a 64-bit system?

Am 13.06.2011 18:45, schrieb Alex Gaynor: > Unfortunately the decision to run 32-bit libs on 64-bit systems is outside > of my control. Given that it *should* work I'm more interested in > diagnosing whether this is a bug of some sort in libmysqlclient or a bug in > my code/build procedure. Yo

Re: Bug using 32-bit libmysqlclient on a 64-bit system?

Unfortunately the decision to run 32-bit libs on 64-bit systems is outside of my control. Given that it *should* work I'm more interested in diagnosing whether this is a bug of some sort in libmysqlclient or a bug in my code/build procedure. Alex On Sat, Jun 4, 2011 at 10:06 AM, walter harms wr

Re: Bug using 32-bit libmysqlclient on a 64-bit system?

It is basicly a not clever solution to run 32bit libs with a 64bit system. You have to compile -m32 and all sort of things. It is *way* better to compile with pure 64bit. re, wh Am 04.06.2011 02:18, schrieb Alex Gaynor: > I've got a 64-bit Linux system, with a 32-bit libmysqlclient (and a 64-bit

Re: Re bug#45458

egiv...@gmail.com [mailto:vegiv...@gmail.com] On Behalf Of Johan De > Meersman > Sent: Wednesday, March 03, 2010 6:16 AM > To: Zardosht Kasheff > Cc: Jonas Oreland; mysql@lists.mysql.com > Subject: Re: Re bug#45458 > > Unless I'm very much mistaken, InnoDB tables always have a clu

RE: Re bug#45458

Yes, but the optimizer doesn't know that. -Original Message- From: vegiv...@gmail.com [mailto:vegiv...@gmail.com] On Behalf Of Johan De Meersman Sent: Wednesday, March 03, 2010 6:16 AM To: Zardosht Kasheff Cc: Jonas Oreland; mysql@lists.mysql.com Subject: Re: Re bug#45458 Unles

Re: Re bug#45458

Unless I'm very much mistaken, InnoDB tables always have a clustered index as their primary key. On Wed, Mar 3, 2010 at 2:58 PM, Zardosht Kasheff wrote: > Hello Jonas, > > Thank you for filing this feature request. Are there plans to add > support for clustered indexes in MySQL soon? This is som

Re: Re bug#45458

Hello Jonas, Thank you for filing this feature request. Are there plans to add support for clustered indexes in MySQL soon? This is something I have been researching on and off for a while now. Here are my thoughts. It seems that there are two parts to this feature request: 1) a new flag that all

Re bug#45458

Hi, I just filed http://bugs.mysql.com/bug.php?id=51687 which is very related to your bug#45458. If you would care to look at it and provide feedback, I would appreciate it. /Jonas -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mys

Re: Bug? Distinct AS with Order By

> From: Glyn Astill > > Doesn't look crazy to me, and it works in 5.0.32 > > http://www.privatepaste.com/50RvhihKKm > > Perhaps time to patch that server ... > I've guessed at the table def there, obviously your def may be different and that would surely affect the palanners choice. Perhaps

Re: Bug? Distinct AS with Order By

> From: Matt Neimeyer > > Generic code to draw a SELECT element on the screen > sometimes it ends > up like such... > > SELECT DISTINCT name AS myvalue,name AS mydisp FROM names > WHERE > name!="" ORDER BY myvalue > > On 4.1.22 this returns > > A A > B B > C C > D D > > On 5.0.22 this returns

Re: Bug: Different data for different connections

On 20.12.2007 22:46 CE(S)T, Martijn Tonies wrote: >> Okay, I got that. So a COMMIT statement after disabling autocommit mode >> and another START TRANSACTION does not finish my transaction. (But then, >> what does?) Interesting view, I didn't know that. But now all's clear: I >> won't touch autocom

Re: Bug: Different data for different connections

> >> So MySQL does support nested transaction and both "SET AUTOCOMMIT = 0" > >> and "START TRANSACTION" start a new transaction level, is that true? > > > > I didn't say it supports nested transactions, I said that if your > > application > > starts a single transaction and does not finish it, it

Re: Bug: Different data for different connections

On 20.12.2007 21:34 CE(S)T, Martijn Tonies wrote: >> So MySQL does support nested transaction and both "SET AUTOCOMMIT = 0" >> and "START TRANSACTION" start a new transaction level, is that true? > > I didn't say it supports nested transactions, I said that if your > application > starts a single

Re: Bug: Different data for different connections

On 20.12.2007 22:18 CE(S)T, Baron Schwartz wrote: > On Dec 20, 2007 3:33 PM, Yves Goergen <[EMAIL PROTECTED]> wrote: >> I wasn't able to find MVCC-related information (I assume it means Multi >> Version Concurrency Control, not sure whether that's correct) in the >> MySQL manual. But Martijn's expl

Re: Bug: Different data for different connections

Hi, On Dec 20, 2007 3:33 PM, Yves Goergen <[EMAIL PROTECTED]> wrote: > On 20.12.2007 21:14 CE(S)T, Baron Schwartz wrote: > > It doesn't support nested transactions. What you're seeing is the > > effects of MVCC. The InnoDB section of the MySQL manual explains it. > > I wasn't able to find MVCC-r

Re: Bug: Different data for different connections

> On 20.12.2007 20:34 CE(S)T, Martijn Tonies wrote: > > Are your tables InnoDB? If so, the snapshot transaction is giving you > > a static view on the data and your own changes, while your PHPMyAdmin > > commits the NULL write. Your application keeps on seeing your own > > changes, cause it did

Re: Bug: Different data for different connections

On 20.12.2007 21:14 CE(S)T, Baron Schwartz wrote: > It doesn't support nested transactions. What you're seeing is the > effects of MVCC. The InnoDB section of the MySQL manual explains it. I wasn't able to find MVCC-related information (I assume it means Multi Version Concurrency Control, not su

Re: Bug: Different data for different connections

On 20.12.2007 20:34 CE(S)T, Martijn Tonies wrote: > Are your tables InnoDB? If so, the snapshot transaction is giving you > a static view on the data and your own changes, while your PHPMyAdmin > commits the NULL write. Your application keeps on seeing your own > changes, cause it did not end the s

Re: Bug: Different data for different connections

Hi, On Dec 20, 2007 2:26 PM, Yves Goergen <[EMAIL PROTECTED]> wrote: > On 20.12.2007 19:42 CE(S)T, Yves Goergen wrote: > > But when I set that column to NULL > > with phpMyAdmin, my application still reads the old data from the > > database. phpMyAdmin keeps telling me that the value is actually N

Re: Bug: Different data for different connections

Yves, > On 20.12.2007 19:42 CE(S)T, Yves Goergen wrote: > > But when I set that column to NULL > > with phpMyAdmin, my application still reads the old data from the > > database. phpMyAdmin keeps telling me that the value is actually NULL, > > which I just entered. Whereas the persistent PHP conn

Re: Bug: Different data for different connections

On 20.12.2007 19:42 CE(S)T, Yves Goergen wrote: > But when I set that column to NULL > with phpMyAdmin, my application still reads the old data from the > database. phpMyAdmin keeps telling me that the value is actually NULL, > which I just entered. Whereas the persistent PHP connection doesn't see

RE: BUG: DATE_ADD 99999 fails, but 9999 works.

> From: Daevid Vincent [mailto:[EMAIL PROTECTED] > Sent: Monday, August 27, 2007 6:09 PM > To: 'MySQL General' > Cc: 'Chris' > Subject: RE: BUG: DATE_ADD 9 fails, but works. > > > -Original Message- > > From: Chris [mailto:[EMAIL

Re: BUG: DATE_ADD 99999 fails, but 9999 works.

On 8/27/07, Daevid Vincent <[EMAIL PROTECTED]> wrote: > Fortune 500 companies You mean in 21 years from now, all this will > just fail miserably because of some obscure 2038 limitation? This is Y2K > all over again -- unless mySQL fixes this bug. Obscure? Not really - lots of software is going

Re: BUG: DATE_ADD 99999 fails, but 9999 works.

At 5:44 PM -0700 8/27/07, Chris wrote: I don't think this is a bug. I think what's happening is that your timestamp column can't hold that date, it's max value is somewhere in 2038. So I guess either change your timestamp column to a datetime column, or prevent users from putting invalid da

RE: BUG: DATE_ADD 99999 fails, but 9999 works.

> -Original Message- > From: Chris [mailto:[EMAIL PROTECTED] > Sent: Monday, August 27, 2007 5:45 PM > > I don't think this is a bug. I think what's happening is that your > timestamp column can't hold that date, it's max value is > somewhere in 2038. You appear to be correct, burried i

Re: BUG: DATE_ADD 99999 fails, but 9999 works.

I don't think this is a bug. I think what's happening is that your timestamp column can't hold that date, it's max value is somewhere in 2038. So I guess either change your timestamp column to a datetime column, or prevent users from putting invalid data in. Daevid Vincent wrote: using

RE: BUG: DATE_ADD 99999 fails, but 9999 works.

> -Original Message- > From: Paul DuBois [mailto:[EMAIL PROTECTED] > Sent: Monday, August 27, 2007 5:04 PM > To: Daevid Vincent; 'MySQL General' > Subject: Re: BUG: DATE_ADD 9 fails, but works. > > At 4:56 PM -0700 8/27/07, Daevid Vincent wrote:

Re: BUG: DATE_ADD 99999 fails, but 9999 works.

At 4:56 PM -0700 8/27/07, Daevid Vincent wrote: using 9 as the DATE_ADD interval value will result in 000-00-00 but one less 9 will work. root# mysql --version mysql Ver 14.12 Distrib 5.0.41, for pc-linux-gnu (i686) using EditLine wrapper CREATE TABLE `Users` ( `CoreID` int(10) unsi

Re: BUG in UNION implementation?! Confimation or Explaination please

On Wednesday 11 July 2007 00:34, Anders Karlsson wrote: > UNION will only return distinct rows. This is according to spec and to > the SQL Standard. And of course, to no one's surprise, this also matches the mathematical definition of union: j -- Joshua Kugler Lead

RE: BUG in UNION implementation?! Confimation or Explaination please

UNION is mean to removed duplicate rows. Use "UNION ALL" if you don't want this to happen. http://dev.mysql.com/doc/refman/5.0/en/union.html -Original Message- From: list account [mailto:[EMAIL PROTECTED] Sent: 11 July 2007 09:19 To: mysql@lists.mysql.com Subject: BUG in UNION implementat

Re: BUG in UNION implementation?! Confimation or Explaination please

UNION will only return distinct rows. This is according to spec and to the SQL Standard. To avoid this, use UNION ALL instead of UNION. Try that with your queries and you'll see that this will do the trick. This is, as I said, in accordance with the standard and the way all SQL based databases

Re: bug

ajay roy wrote: > i am getting the error somthing like that > > GET ERROR(127) TABLE HANDLER PROBLEM > stormcrow|~$ perror 127 Error code 127: Unknown error 127 MySQL error: 127 = Record-file is crashed -- raj shekhar facts: http://rajshekhar.net | opinions: http://rajshekhar.net/blog I dar

Re: bug

Ajay, To lookup the string for an error code use the perror utility: $ perror 127 MySQL error code 127: Record-file is crashed Try running repair table. See http://dev.mysql.com/doc/refman/5.0/en/repair.html for more details. -Eric On 12/17/06, ajay roy <[EMAIL PROTECTED]> wrote: i am gettin

Re: Bug or No bug - Composite Unique Key using null values

> I have been mulling over this for a few days reading docs and going back and > forth with people on this, so I figured I would come here before writing up a > bug report. > > First of all, I have tested this on 4.1.18, 5.0.16, and 5.0.22 within Solaris > 9 and Mandrake Linux LE 2005 environments

Re: Bug or No bug - Composite Unique Key using null values

Dan, this is documented behavior: http://dev.mysql.com/doc/refman/5.0/en/create-index.html Specifically, "A UNIQUE index creates a constraint such that all values in the index must be distinct. An error occurs if you try to add a new row with a key value that matches an existing row. This constrai

Re: bug in simple select, what is going on?

kmh496 wrote: hi, i am running a join query between the german_english table and the user_todo_german_english tables, to figure out which words a user is studying. the key i am using is a combination of wordid + pos + posn (that is part of speech == pos) however, i am not able to correctly do the

Re: [SPAM] Re: bug in simple select, what is going on?

2006-04-22 (토), 00:49 +0100, Philippe Poelvoorde 쓰시길: > Hi, > > > mysql> select * from user_todo_german_english where wordid = '86851' and > > posn = '1' and pos = 'm' AND mb_id='curious'; > > +-++--+--+-+ > > | mb_id | wordid | posn | pos | date_col

Re: bug in simple select, what is going on?

2006-04-22 (토), 08:43 +0900, kmh496 쓰시길: > hi, > i am running a join query between the german_english table and the > user_todo_german_english tables, to figure out which words a user is > studying. > the key i am using is a combination of wordid + pos + posn (that is part > of speech == pos) > how

Re: bug in simple select, what is going on?

Hi, > mysql> select * from user_todo_german_english where wordid = '86851' and > posn = '1' and pos = 'm' AND mb_id='curious'; > +-++--+--+-+ > | mb_id | wordid | posn | pos | date_col| > +-++--+--+-

Re: bug in MySQL 5?

Octavian Rasnita wrote: From: "Gleb Paharenko" <[EMAIL PROTECTED]> Hello. In my opinion, it is not a bug. REPLACE has returned the sum of affected rows - one was deleted, and one was inserted. See: http://dev.mysql.com/doc/refman/5.1/en/replace.html Thank you. I have seen that's the true. I

Re: bug in MySQL 5?

From: "Gleb Paharenko" <[EMAIL PROTECTED]> > Hello. > > In my opinion, it is not a bug. REPLACE has returned the sum > of affected rows - one was deleted, and one was inserted. See: > http://dev.mysql.com/doc/refman/5.1/en/replace.html > > Thank you. I have seen that's the true. Is there any

Re: bug in MySQL 5?

Hello. In my opinion, it is not a bug. REPLACE has returned the sum of affected rows - one was deleted, and one was inserted. See: http://dev.mysql.com/doc/refman/5.1/en/replace.html Octavian Rasnita wrote: > Hi, > > I have tried: > > mysql> create table z(id int unsigned not n

Re: Bug on MySQl 5.0.15 ?

Dyego Souza Dantas Leal <[EMAIL PROTECTED]> wrote on 11/07/2005 12:57:13 PM: > Hello guys.. > > > I'm trying to use MySQL 5.0.15 , but my applications not work > > The Select : > > select PEDCERT.id as idped,count(*),'CE' as cer > from asddb.PEDCERT, asddb.MOVIMENTO m > where m.dat >= '2005/0

Re: Bug on MySQl 5.0.15 ?

At 15:57 -0200 11/7/05, Dyego Souza Dantas Leal wrote: Hello guys.. I'm trying to use MySQL 5.0.15 , but my applications not work The Select : select PEDCERT.id as idped,count(*),'CE' as cer from asddb.PEDCERT, asddb.MOVIMENTO m where m.dat >= '2005/01/01' and m.dat <= '2005/12/31' and PEDCER

Re: Bug? Set Null Value in NOT NULL field...

Hi! LMS wrote: Jeff Smelser escribió: On Wednesday 26 October 2005 04:24 pm, LMS wrote: Hi, I have this structure: --- CREATE TABLE tabla ( id int(10) unsigned NOT NULL auto_increment, nombre varchar(100) NOT NULL default '', because your d

Re: Bug? Set Null Value in NOT NULL field...

Jeff Smelser escribió: On Wednesday 26 October 2005 04:24 pm, LMS wrote: Hi, I have this structure: --- CREATE TABLE tabla ( id int(10) unsigned NOT NULL auto_increment, nombre varchar(100) NOT NULL default '', because your defaulting it to ''.

Re: Bug? Set Null Value in NOT NULL field...

On Wednesday 26 October 2005 04:24 pm, LMS wrote: > Hi, > I have this structure: > --- > CREATE TABLE tabla ( >id int(10) unsigned NOT NULL auto_increment, >nombre varchar(100) NOT NULL default '', because your defaulting it to ''.. so null = ''

Re: Bug in 4.0? 'CREATE TABLE `db`.`table ..' fails silently on replication slave

Hello. Manual says that --replicate-do-db: " Tells the slave to restrict replication to statements where the default database (that is, the one selected by USE) is db_name." Note that this does not replicate cross-database statements, check what is your default database, when you're running

Re: Bug in 4.0? 'CREATE TABLE `db`.`table ..' fails silently on replication slave

More investigation shows that the query does make it to the slave, at least into the relay log, yet it's still ignored. 'replicate-do-db' is set and shows the correct DB in the slave status. Atle - Flying Crocodile Inc, Unix Systems Administrator On Thu, 20 Oct 2005, Atle Veka wrote: > I ran in

Re: Bug in 4.0? 'CREATE TABLE `db`.`table ..' fails silently on replication slave

Hello. > the query entered into the binlog, however the slave ignores it >silently: Check your server's relay logs if they contains this statement. See: http://dev.mysql.com/doc/refman/5.0/en/replication-problems.html http://dev.mysql.com/doc/refman/5.0/en/slave-logs.html Check that

Re: bug report

Hello. Please, could you send a more detailed report. Include information about MySQL and operating system versions. See: http://dev.mysql.com/doc/mysql/en/Bug_reports.html You may want to force a recovery. See: http://dev.mysql.com/doc/mysql/en/forcing-recovery.html Pierre-Henry

Re: BUG on SELECT

Hello. See: http://dev.mysql.com/doc/mysql/en/Bug_reports.html I think that your bug is related to bug #6303. "Federico J. Fernandez" <[EMAIL PROTECTED]> wrote: > > Hi, > > i'm using mysql-alpha ver 5.0.2. > > while i was using a cgi script, i discovered that SELECT querys us

Re: Bug? Can't create/write to file '/root/tmp/ibu6vdue' (Errcode: 13)

tables http://www.innodb.com/order.php - Original Message - From: ""Alejandro D. Burne"" <[EMAIL PROTECTED]> Newsgroups: mailing.database.myodbc Sent: Monday, December 06, 2004 2:40 PM Subject: Re: Bug? Can't create/write to file '/root/tmp/ibu6vdue&

Re: Bug? Can't create/write to file '/root/tmp/ibu6vdue' (Errcode: 13)

Heikki I do it, in my.cnf on [mysqld] section I add: tmpdir=/tmp then I try: /usr/bin/mysqld_safe --tmpdir=/tmp --datadir=/var/lib/mysql --user=mysql with the same result If I change TMPDIR enviroment variable to /tmp works fine. I forgot to say I install mysql from rpm. Alejandro On Fri, 3 D

Re: Bug? Can't create/write to file '/root/tmp/ibu6vdue' (Errcode: 13)

Alejandro, - Original Message - From: ""Alejandro D. Burne"" <[EMAIL PROTECTED]> Newsgroups: mailing.database.myodbc Sent: Friday, December 03, 2004 7:20 PM Subject: Bug? Can't create/write to file '/root/tmp/ibu6vdue' (Errcode: 13) After installing MySQL 5.0.2 on MDK10.0 mysqld doesn't

Re: bug or feature, <> 'blah' does NOT work with null records

> > Fortunately there is function COALESCE() that will return the first argument > > that is not NULL. In case of NULL values you can use a default value for an > > expression: COALESCE( `col`*2, 14) will produce 14 if `col` is NULL. > > FWIW, IFNULL() does the same thing, with a clearer (to me) n

Re: bug or feature, <> 'blah' does NOT work with null records

On Thu, Oct 28, 2004 at 11:50:12AM +0200, Jigal van Hemert wrote: ... > Fortunately there is function COALESCE() that will return the first argument > that is not NULL. In case of NULL values you can use a default value for an > expression: COALESCE( `col`*2, 14) will produce 14 if `col` is NULL.

Re: bug or feature, <> 'blah' does NOT work with null records

From: "Harald Fuchs" <[EMAIL PROTECTED]> > In article <[EMAIL PROTECTED]>, > "Jigal van Hemert" <[EMAIL PROTECTED]> writes: > > > Fortunately there is function COALESCE() that will return the first argument > > that is not NULL. In case of NULL values you can use a default value for an > > expres

Re: bug or feature, <> 'blah' does NOT work with null records

In article <[EMAIL PROTECTED]>, "Jigal van Hemert" <[EMAIL PROTECTED]> writes: > NULL is meant to indicate that the value is unknown. If a value is unknown > it can be anything. > So, in the example `col` <> 'blah', col can be anything, including 'blah'. > If you take that into consideration the o

Re: bug or feature, <> 'blah' does NOT work with null records

From: "Harald Fuchs" <[EMAIL PROTECTED]> > Yes, of course. "NULL <> 'blah'" returns NULL, and that's perfectly > standards-conformant. Furthermore, it's quite logical. NULL is meant to indicate that the value is unknown. If a value is unknown it can be anything. So, in the example `col` <> 'bla

Re: bug or feature, <> 'blah' does NOT work with null records

In article <[EMAIL PROTECTED]>, matt_lists <[EMAIL PROTECTED]> writes: > I cant tell if this is a bug or a feature. > Select from table where col <> 'blah' > I use this all the time with other databases, works great, gives me > everything that's not "blah" If those "other databases" return also

Re: bug or feature, <> 'blah' does NOT work with null records

MySQL also has a work around. You might try to rephrase your comparison as WHERE not col <=> 'blah' the "<=>" operator is documented as a null-enabled equality check. That way if you are comparing null to null, you get a true or false and not another null. This comparator is available as of 3

Re: bug or feature, <> 'blah' does NOT work with null records

At 14:51 -0400 10/25/04, matt_lists wrote: I cant tell if this is a bug or a feature. Select from table where col <> 'blah' I use this all the time with other databases, works great, gives me everything that's not "blah" but in mysql, it wont work if there's null records in the table That is the

Re: bug or feature, <> 'blah' does NOT work with null records

matt_lists wrote: I cant tell if this is a bug or a feature. Select from table where col <> 'blah' I use this all the time with other databases, works great, gives me everything that's not "blah" In SQL (not just MySQL), any comparisons involving NULL return NULL, so if that was working in some o

RE: bug or feature, <> 'blah' does NOT work with null records

[snip] I cant tell if this is a bug or a feature. Select from table where col <> 'blah' I use this all the time with other databases, works great, gives me everything that's not "blah" but in mysql, it wont work if there's null records in the table I have to do this, select from table where (

Re: Bug #3933

Stardate [040822 01:45]. Sergei Golubchik of Borg wrote: > Ah, ok. > Here it is: > > http://mysql.bkbits.net:8080/mysql-4.0/[EMAIL PROTECTED] > > Regards, > Sergei > Thanks -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[

Re: Bug #3933

Hi! On Aug 22, Robert Nagy wrote: > Stardate [040822 00:26]. Sergei Golubchik of Borg wrote: > > Roger, it is explained my reply to the bugreport, and in my reply to > > you. > Thanks I can read. But the question was not that. > > > > http://www.mysql.com/doc/en/Installing_source_tree.html > > >

Re: Bug #3933

Stardate [040822 00:26]. Sergei Golubchik of Borg wrote: > Roger, it is explained my reply to the bugreport, and in my reply to > you. Thanks I can read. But the question was not that. > > http://www.mysql.com/doc/en/Installing_source_tree.html > I'd like to see the diff between the two revisions

Re: Bug #3933

Hi! On Aug 21, Robert Nagy wrote: > Hi. Can u point me to the fixed file(s) please? > Or can u send me the diff if you have it? > http://bugs.mysql.com/bug.php?id=3933 Roger, it is explained my reply to the bugreport, and in my reply to you. The bug is fixed in 4.0.21. According to the manual h

RE: bug

Who did you log in as? -Original Message- From: Farnaz Akhavi To: [EMAIL PROTECTED] Sent: 8/10/04 9:57 AM Subject: bug I have downloaded and installed MYSQL Client/Server 4.0. 1. when I get a query on SHOW DATABASES, it only shows "test" and not "mysql" which has the users info 2. It d

Re: Bug-Report: mysqld 4.1.3 crashes on startup

Hi! On Aug 01, Helge Jung wrote: > >Description: > When I start up my fresh compiled mysqld it crashes immediately, the > error log file says: It was reported just a few hours ago at bugs.mysql.com (which is the recommended way to report bugs, by the way :) you may follow the progress using htt

Re: Bug in fulltext index creation

Hi again. PROCESS LIST is: Creating tmp file Repair by sorting The problem occurs while repair by sorting. myisam parameters have been increased accordingly: myisam max extra sort file size = 15000M myisam max sort file size = 15000M There must be a bug somewhere? What do you suggest? Vincent Hi!

Re: Bug in fulltext index creation on very huge sets of data?

Hi! On Jul 06, Vincent Bouret wrote: > Hi, > > I got the following values: > key_buffer_size = 256M > myisam max extra sort file size = 8000M > myisam max sort file size = 8000M > myisam sort buffer size = 128M > > But that big table (MYD = 2397 MB), rows = 5 355 866 still won't index > in full

Re: Bug in fulltext index creation on very huge sets of data?

Hi, I got the following values: key_buffer_size = 256M myisam max extra sort file size = 8000M myisam max sort file size = 8000M myisam sort buffer size = 128M But that big table (MYD = 2397 MB), rows = 5 355 866 still won't index in full text. Disk space is enough (25GB of free space), no error

Re: Bug in 4.0.20

On Fri, 2004-06-11 at 08:50, Egor Egorov wrote: > Wendell Dingus <[EMAIL PROTECTED]> wrote: > > > RedHat Enterprise 3WS, fully up2date. MySQL binary RPMs for AMD64 won't even > > start for me, what were they built on?. I installed the .src.rpm and built one > > myself (-bb --target amd64). Install

Re: Bug in 4.0.20

Wendell Dingus <[EMAIL PROTECTED]> wrote: > RedHat Enterprise 3WS, fully up2date. MySQL binary RPMs for AMD64 won't even > start for me, what were they built on?. I installed the .src.rpm and built one > myself (-bb --target amd64). Installed that and all seems well. This seems strange. Can you p

Re: Bug? MySQL 4.1.2 and OS X 10.3.4

On Jun 1, 2004, at 5:04 PM, Greg Willits wrote: So, - G4/OS X Server: 4.0.20 installs fine, but 4.2.1 does not on 10.3.4 - G3/OS X Standard: 4.2.1 installs fine on 10.3.2, but after 10.3.4 Standard was installed, 4.2.1 did not work, yet 4.0.20 continues to install fine The fact that 4.0.20 will

Re: [BUG] Error: Mem area size is 0. Possibly a memory overrun

Hi! This is a bug that is fixed in upcoming 4.0.21. See below for a workaround. " If you configure innodb_additional_mem_pool_size so small that InnoDB memory allocation spills over from it, then every 4 billionth spill may cause memory corruption. A symptom is a printout like below in the `.err

Re: bug?

"Anders Gjermshus" <[EMAIL PROTECTED]> wrote: > In the mysql documentation it stands: > > max_user_connections > > The maximum number of simultaneous connections allowed to any given MySQL > account. A value of 0 means ``no limit.'' This variable was added in MySQL > 3.23.34. > > > > In my con

Re: BUG and workaround (Was: Table lock problem on INSERT with FULLTEXT index?)

Success with the bug entry. Nice system, too. http://bugs.mysql.com/bug.php?id=3483 Thanks, Don Don MacAskill wrote: This problem is completely repeatable, I'm not the only one having it, and I've found a (temporary) workaround. I'm not sure if it affects other machines than AMD64, but it

Re: Bug in MySQL with Correlated Subqueries?

Are you saying this is a bug which has already been fixed for the next release? In any case, it may be worth noting that the manual says correlated subqueries "are inefficient and likely to be slow. Rewriting the query as a join might improve performance."

Re: Bug in MySQL with Correlated Subqueries?

At 13:59 27/3/2004, Ed Smith wrote: Hi, Below the results from a server built with BK 4.1 tree 3 days ago: C:\mysql\bin>mysqld --standalone --console --ansi --default-table-type=innodb 040328 0:36:59 InnoDB: Started; log sequence number 0 43634 mysqld: ready for connections. Version: '4.1.2-alpha

Re: BUG?

More of the same: mysql> select 260.22 + 18.81 - 279.03; +-+ | 260.22 + 18.81 - 279.03 | +-+ |

Re: BUG?

[EMAIL PROTECTED] wrote: Arithmetic results in a value of zero but mysql is treating the value as > 0. This is reproducible in a lot of different ways. Below is a pretty clear example. mysql> select version(); +---+ | version() | +---+ | 4.0.17-max-nt | +---

Re: [bug] Temp table cannot be used twice in a query

John Heitmann <[EMAIL PROTECTED]> wrote: > >Description: > > When a temp table is included twice in a query mysql fails with the > error: > > ERROR 1137 at line 9: Can't reopen table: 'foo' > > This happens on both 4.0.17 and 4.0.18. It did not happen on 4.0.14. > > >How-To-Repeat: > > create

Re: Bug on MYSQL-5.0 in statement "OPTIMIZE TABLE"

Hi! On Feb 23, Gelu Gogancea wrote: > Hi, > TABLE CREATE DESCRIPTION : > CREATE TABLE T1(IDAP INT(16),TVAL INT(2),CH_VAL_SEC > INT(16),INDEX(IDAP),INDEX(TVAL),INDEX(CH_VAL_SEC)); > > RUNNING CONDITIONS: > -use persistent connection. What do you mean "persistent connection" ? Persistent PHP conne

Re: Bug in subqueries?

Andreas Pardeike <[EMAIL PROTECTED]> wrote: > Hi List, > should I report the following as a bug? > > mysql> select count(*) from words as w1 where w1.val in (select w2.val > from words as w2 where w2.val like 'm%'); >+--+ > | count(*) | > +--+ >

Re: [BUG] SHOW INDEX bug for fulltext indexes in MySQl 4.0.17

Hi! On Jan 23, Dave Rolsky wrote: > Here's a recipe: > > create table foo (foo text, bar text); > > create fulltext index foo on foo (foo, bar); > > mysql> show index from foo; > > +---++--+--+-+---+-+--++-

  1   2   3   4   5   6   >