#2347 (ok 2.10) slashes are not escaped properly
I got table wit two varchar columns:
CREATE TABLE `pattern` (
`expression` varchar(200) NOT NULL default '',
`comment` varchar(30) default '',
PRIMARY KEY (`expression`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
and data like this:
INSERT INTO `pattern` (`expression`, `comment`) VALUES
('.+^r=.*@foo\\.cz.+$', 'chcou spam'),
('.+^r=.*@bar\\.cz.+$', 'chcou spam'),
('', '.+^r=.*@foobar\\.cz.+$');
when i try to modify any value phpmyadmin returns back to page vith data preview without modification of data and with no error.
Think that the problem will be with escaping characters.
Gentoo linux
mysql Ver 14.12 Distrib 5.0.26, for pc-linux-gnu (x86_64) using readline 5.1 - compiled from sources
phpMyAdmin - 2.10.0-beta1
Firefox 1.5.0.4 for Linux - compiled from sources
Logged In: YES
user_id=326580
Originator: NO
cannot confirm - works for me
Logged In: YES
user_id=1711529
Originator: YES
Tried it again in Opera browser:
- Created new DB.
- Ran SQL commands from report to create table and insert data.
- List data in table (via Browse link) and clicked edit icon on the first row.
- Changed text in comment column to "xxx".
- Clicked "Go" button.
Browser got back to Browse section, row without any modification.
Gentoo linux
mysql Ver 14.12 Distrib 5.0.26, for pc-linux-gnu (x86_64) using readline 5.1 - compiled from sources
phpMyAdmin - 2.10.0-beta1
Opera 8.54 for Linux
Logged In: YES
user_id=326580
Originator: NO
oh, sorry i missread - yes i can confirm
Logged In: YES
user_id=1383652
Originator: NO
weird behaviour confirmed with FF, check example on
http://pma.cihar.com/trunk-config/index.php?db=test :
after edit "expression" becomes a dropout
editing using pma2.11trunk throws an js error (thx FireBUG :) :
syntax error in table_row_action.php
return unNullify('comment', 'CONVERT(`patternEDITED`.`expression` USING utf8) = ...
Logged In: YES
user_id=326580
Originator: NO
this seems to be more than one bug ... the first is not correctly escaped strings in JavaScript - but this does not solve the problem ...
Logged In: YES
user_id=326580
Originator: NO
this seems to be more than one bug ... the first is not correctly escaped strings in JavaScript - but this does not solve the problem ...
Logged In: YES
user_id=326580
Originator: NO
fixed - thanks for reporting
Logged In: YES
user_id=326580
Originator: NO
fixed - thanks for reporting
Logged In: YES
user_id=326580
Originator: NO
fixed - thanks for reporting