Enormous Bug In 5.18, Fixed In 5.19?

[allonzi]

I had an enormous bug in 5.18, I don't know if fixed in next release.

I have a simple table

bl_requetes CREATE TABLE `tbl_requetes` (

`Req_ID` text,

`Req_Sql` text,

`Req_Param` text,

`Req_Description` text,

`Req_Type` int(2) default NULL,

`Req_Libelle` text

) ENGINE=InnoDB DEFAULT CHARSET=latin1 COMMENT='InnoDB free: 8192 kB'

while editing the field req_sql in sqlyog 5.18, when I saved, it replaced ALL rows in the table by the row I was editing!!! Great! Everything is destroyed.

I had it just once. 😡

[peterlaursen]

One thread per question only please!

Does this answer you question?

http://webyog.com/faq/28_70_en.html

EVERY database client does so, with identical rows!

If not then explain your self more in detail.

[peterlaursen]

Now ..

It seems that I have a mail from a developer. There is an issue. I do not usnderstand details. It is fixed in the 5.2 beta 4 tree, I was told

[peterlaursen]

What we can reproduce with this schema is that if more rows have the same value for the numerical field and you change that numerical field (not a text filed) SQLyog sends SQL like

Code:

update `tbl_requetes` set `Req_ID`='abc',`Req_Sql`='def', `Req_Param`='ghi' ,`Req_Description`='jkl' ,`Req_Type`='2' ,`Req_Libelle`='mno' where `Req_Type`='1';

what results in all rows having `Req_Type`='1' to become updated even if the text fileds are not identical.

The where-clause:

Code:

where `Req_Type`='1';

would be OK if that field was a PK. But it is not and it is a bug.

[peterlaursen]

… but you really SHOULD have a primary key in the table because without a PK the WHERE-condition must include all columns. With such WHERE MySQL cannot use indexes at all and with some data in the database an update can be very slow.

BTW: do you have any particular reason to use TEXTs for all fields and not VARCHARS ?

[Author]

Posts