-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi devels,
it looks as if MySQL has silently deprecated the BINARY sttribute in
MySQL 4.1. If you create a CHAR(3) BINARY field, it becomes CHAR(3)
CHARACTER SET latin1 COLLATE latin1_bin.
Old [VAR]CHAR BINARY fields are mapped to [VAR]BINARY. This leads us to
various incompatibilities:
1) We don't have these fields in our list of possible table fields and I
don't know if MySQL 3.23.32 supports the syntax, so adding them
generally wouldn't we a good idea, imho.
2) tbl_properties_structure.php recognizes these fields correctly as
binary fields, but strips off the string "BINARY", so "VARBINARY(20)"
becomes "var(20)" and even worse "BINARY(20)" becomes "(20)".
3) when trying to alter these fields, both are recognized as VARCHAR
BINARY, which is dangerous because if we just want to change the size
for instance, they get changed to "VARCHAR CHARACTER SET latin1 COLLATE
latin1_bin"...
3) The binary column in tbl_properties_structure is superfluous, imho.
And so is the BINARY entry in the list of field attributes.
4) The parser does not recognize BINARY as column type.
Here's a simple table for reproducing the problem:
CREATE TABLE `binarytest` (
`one` binary(3),
`two` varbinary(10)
)
- --
Alexander M. Turek
<rabus(a)users.sourceforge.net>
_ __ __ _ _ _
_ __ | |__ _ __ | \/ |_ _ / \ __| |_ __ ___ (_)_ __
| '_ \| '_ \| '_ \| |\/| | | | | / _ \ / _` | '_ ` _ \| | '_ \
| |_) | | | | |_) | | | | |_| |/ ___ \ (_| | | | | | | | | | |
| .__/|_| |_| .__/|_| |_|\__, /_/ \_\__,_|_| |_| |_|_|_| |_|
|_| |_| |___/
<http://www.phpmyadmin.net>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBC+XHoHdnxuobFY4RAl5MAJ9rhasmTe78CKqEPzqnXC1NjSdtnACfQaiO
C5a5uEpLgo0zrS/QBSxGH1k=
=IzsE
-----END PGP SIGNATURE-----
Hi,
I know that we have piles of "bug" reports, and seeing things continue
like this, I think a decision must be made about 2.6.0.
I would be ready this week-end to start a list of show-stoppers, then
discuss about it and about a schedule for -rc1.
Marc
Hi,
if someone has an idea, I would be grateful :)
1. I have 49 databases in the left frame. With Mozilla 1.6 /Linux
or Netscape 7.1 /Win98, I cannot scroll in left frame (Light mode).
It works in IE 6/ Win98.
2. With the on-screen export in textarea, I have a table with a
BLOB field and 3 rows. Only one row has some contents in the BLOB
(4.3K). When I export on-screen (I asked for hexadecimal format), the
line is blank for this row in Mozilla 1.6 /Linux, the line is full of
garbage in Netscape 7.1 /Win98, and all is ok in IE 6 / Win98.
Can someone reproduce this?
Marc
Hi Michal,
I don't know why we use a textarea now. Probably some cut & paste issues. Maybe Michael Keck or Alexander have an idea about this.
Marc
-----Original Message-----
From: Michal Čihař <michal(a)cihar.com>
To: phpmyadmin-devel(a)lists.sourceforge.net
Date: Mon, 12 Jul 2004 21:18:57 +0200
Subject: Re: [Phpmyadmin-devel] current cvs: 2 problems
Hi
back from vacation :-)
Marc Delisle wrote:
> Garvin Hicking wrote:
>
>> Hi Marc!
>>
>>
>>>> I imported your file and after that clicked on "export" with latest
>>>> CVS. I get
>>>> the exact same dump data than the file you sent...
>>>
>>>
>>> Which browser and OS? And are you talking about the on-screen dump?
>>> This
>>> is were the problem is.
>>
>>
>>
>> Firefox 0.8, Windows 2000, using German ISO-8859-1 language. And I'm
>> talking
>> about the straight-into-textarea dump plus [x] binary checkbox...
>>
>> Regards,
>> Garvin.
>>
>
> Ok then, so now we have on the working side, Firefox 0.8 / Win2K
> and IE 6 / Win98.
>
> On the non-working side: Moz 1.6 / Linux, Netscape 7.1 / Win98.
>
> Can someone confirm one of my non-working cases?
Firefox 0.8 / Linux - empty line, saved file is fine. Probably some
browser limit is hit - 4k chars per line, or something like that ... why
do we use texarea? <pre> used before was IMHO fine.
--
Michal Čihař | http://cihar.com
