SELECT problem after upgrading from 4.0.20 to 4.1.7

SELECT problem after upgrading from 4.0.20 to 4.1.7

am 09.02.2005 17:53:15 von Steve Hay

--------------000006010100090306030805
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-NAIMIME-Disclaimer: 1
X-NAIMIME-Modified: 1

I have a problem in which a simple SELECT statement that worked fine
under 4.0.20 doesn't work any more after upgrading the database software
to 4.1.7 (but still using the database that was created by 4.0.20). If
I re-create the database using 4.1.7 then the SELECT statement now works
again.

Here are the steps to reproduce the bug (running on Windows XP):

1. Install MySQL 4.0.20 and start the mysqld-max-nt server.

2. Run the attached "create.sql" script to create the database and
insert some data into it.

3. Run the attached "select.sql" script to confirm that the SELECT
statement works fine initially. The output is:

testcol
test

4. Stop the mysqld-max-nt server, install MySQL 4.1.7 over the top of
the 4.0.20 installation and restart the mysqld-max-nt server.

5. Run the "select.sql" script again. This time it outputs nothing. I
believe that the output should have been the same as before.

If you re-run the "create.sql" script and then try the "select.sql"
script once more then the output *is* now as before.

We need to be able to get the SELECT statements working after upgrading
to 4.1.7 without needing to re-create the data. I read section 2.5.2 of
the MySQL 4.1.7 manual ("Upgrading from Version 4.0 to 4.1"), but could
not see anything relevant that I might need to do, hence I am led to
believe that this is bug.

- Steve


------------------------------------------------
Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.

--------------000006010100090306030805
Content-Type: text/plain;
name="create.sql"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="create.sql"

drop database if exists testdb;
create database testdb;
use testdb;
drop table if exists testtbl;
create table testtbl (testcol varchar(16) binary) type=innodb;
insert into testtbl values ('test');

--------------000006010100090306030805
Content-Type: text/plain;
name="select.sql"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="select.sql"

use testdb;
select * from testtbl where upper(testcol) = 'TEST';


--------------000006010100090306030805
Content-Type: text/plain; charset=us-ascii

--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org
--------------000006010100090306030805--

Re: SELECT problem after upgrading from 4.0.20 to 4.1.7

am 10.02.2005 10:06:43 von Sergei Golubchik

Hi!

On Feb 09, Steve Hay wrote:
> I have a problem in which a simple SELECT statement that worked fine
> under 4.0.20 doesn't work any more after upgrading the database software
> to 4.1.7 (but still using the database that was created by 4.0.20). If
> I re-create the database using 4.1.7 then the SELECT statement now works
> again.
....
> We need to be able to get the SELECT statements working after upgrading
> to 4.1.7 without needing to re-create the data. I read section 2.5.2 of
> the MySQL 4.1.7 manual ("Upgrading from Version 4.0 to 4.1"), but could
> not see anything relevant that I might need to do, hence I am led to
> believe that this is bug.

It was a bug.
According to http://dev.mysql.com/doc/mysql/en/news-4-1-8.html

The server was interpreting CHAR BINARY and VARCHAR BINARY columns
from 4.0 tables as having the BINARY and VARBINARY data types. Now
they are interpreted as CHAR and VARCHAR columns that have the binary
collation of the column's character set. (This is the same way that
CHAR BINARY and VARCHAR BINARY are handled for new tables created in
4.1.)

Regards,
Sergei

--
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Sergei Golubchik
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Senior Software Developer
/_/ /_/\_, /___/\___\_\___/ Osnabrueck, Germany
<___/ www.mysql.com

--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org