#3672 (ok 4.0) Grid editing destroying huge amount of data


Version using Firefox 15 MySql

After selecting 42 records with
SELECT T1.`dataname`, T1.`data` FROM `orders` AS T1 WHERE T1.`ordernbr` = '248753'

an inline editing of one of the records was made.
As a result the following SQL was executed

UPDATE `mybase`.`orders` SET `data` = 'Lastname' WHERE `orders`.`dataname` = 'lastname';

As a result the last name field in around 200,000 orders now have the same value !


  • Marc Delisle

    Marc Delisle - 2012-08-31

    Can you attach an export of the structure and some sample data?

  • Jørgen Thomsen

    Jørgen Thomsen - 2012-09-02

    Sample data uploaded

  • upscope

    upscope - 2012-09-11

    Running phpMyAdmin under openSUSE12.2 GM Release I have same problem, This is a disaster. I keep my Lions Club members list and I now have 7 members with same last name. Seems to be an intermittent proble. Yestday it happened when I enter two new members, Last names McKay and McKean. Looked like it happeen when first two letters of last name were the same. Today it was when I modified one name (Crapson) and it affected 7 other rows. This did not happen under previous version of phpmyadmin. Version was from openSUSE 12.2 repo.

    Here is a sample of sql executed yesterday:
    INSERT INTO `Lions`.`Moses Lake Lions` (`Member Number`, `First Name`, `Last Name`, `Spouse Name`, `Address`, `City`, `State`, `Zip-Code`, `Join Date`, `Email Address`, `Phone Number`, `Membership Type`, `Cell Phone`, `Occupation40`) VALUES (NULL, 'Denise', 'McKAY', '', '182 Road 1.3 NE', 'Moses Lake', 'WA.', '98837', '2012-07-18', 'DCM065@aol.com', '509-350-8197', 'Regular', '', '');

    I will try and find newer version of phpmyadmin in openSUSE factory repo. When I update from terimal manual it does not appear to happen.


  • Marc Delisle

    Marc Delisle - 2012-09-26
    • assigned_to: nobody --> lem9
  • Marc Delisle

    Marc Delisle - 2012-09-26

    please give me a step-by-step scenario to reproduce the problem, with the sample table you attached.

  • Jørgen Thomsen

    Jørgen Thomsen - 2012-09-26

    Small table for testing

  • Jørgen Thomsen

    Jørgen Thomsen - 2012-09-26

    Do exactly as described.
    Execute the SELECT stement in the SQL window
    Click on the data field next to the dataname field 'lastname' and change its value
    Click outside the field

    The problem must be caused by the logic ignoring the non-displayed fields of the record.

    A new test file matching the problem report has been uploaded.

  • Marc Delisle

    Marc Delisle - 2012-09-27

    Yes, this is the cause of the problem and I'm looking for a solution.

  • Marc Delisle

    Marc Delisle - 2012-09-30

    Note: it's not only a grid editing problem. Clicking on Edit and changing a piece of data has the same problem.

  • Marc Delisle

    Marc Delisle - 2012-10-08
    • priority: 5 --> 1
    • summary: URGENT: Inline editing destroying huge amount of data --> (ok 4.0) Grid editing destroying huge amount of data
    • status: open --> open-fixed
  • Marc Delisle

    Marc Delisle - 2013-05-03
    • Status: open-fixed --> closed-fixed
  • Jørgen Thomsen

    Jørgen Thomsen - 2013-05-05

    This has not been fixed, as the 'solution' apparently is only to prevent updates of views.
    A simple view ('where field like 'x%') of a table with all fields including the primary index field (auto-incrementing int) provides this statement:

    "This table does not contain a unique column. Grid edit, checkbox, Edit, Copy and Delete features are not available."

  • Marc Delisle

    Marc Delisle - 2013-05-05

    I don't understand why you say that it has not been fixed. Can you still destroy huge amount of data? I guess not, as grid editing is deactivated in this case. By the way, this was marked as fixed in October 2012, and we are now in May 2013.

  • Jørgen Thomsen

    Jørgen Thomsen - 2013-05-11

    "fixed in October 2012, and we are now in May 2013." ... when it was released !
    There are people out here who cares about their data and are not downloading and running gamma software.

    I also never understood why such a serious bug was not immediately fixed and released.

    Fixing a problem by preventing people from using a buggy function is not a valid fix in my opinion. A fix is when the bug is removed, so that the function is working as intended.
    In mySQL it is possible to update views under certain conditions. This is not possible now.

    This table does not contain a unique column. Grid edit, checkbox, Edit, Copy and Delete features are not available.

    But the view in question contains all the fields from the primary index !
    (view condition: field like xxx%)
    Furthermore this 'fix' introduces another bug, as even with a primary single field index in the view the above messages is displayed.

    I do not understand, that this was not detected before release.

    Last edit: Jørgen Thomsen 2013-05-11
  • Marc Delisle

    Marc Delisle - 2013-05-12

    Back then, it was decided that the change where a unique key must be present to make the row editable, has such an impact for users that it was better to implement it in the next major version.

    We expect users to test (not run in production as your previous message implies) our alpha, beta and release candidates. The team tries to test, with its limited manpower, but we cannot match testing by the community.

    About the new bug, see https://sourceforge.net/p/phpmyadmin/bugs/3926/.

  • Jørgen Thomsen

    Jørgen Thomsen - 2013-05-15

    I think I have commented on too little testing of phpMyAdmin before. Anyway, I can only repeat, that as phpMyAdmin is used in production environments, then it is imperative, that testing is performed before releases to avoid as many bugs as possible.

    As a developer I know very well, that development is much more fun than testing, but just leave testing to be done by someone else, hopefully, is a bad thing.

    We recovered from our 200.000 lost records due to good backups, but it took some time.

    The attitude of just developing and releasing without thorough testing may be acceptable for a game, but certainly not for software as phpMyAdmin to be used for applications with serious real-world consequences in case of bugs.

    When I look at the recent 4.0 release, I see fancy (debatable) GUI changes, which could easily be delayed for 3 months without any implications for anyone, but probably fun to program. Those 3 months would be better used for testing.

    So, please, developers, get your priorities right.

    Last edit: Jørgen Thomsen 2013-05-15
  • Michal Čihař

    Michal Čihař - 2013-06-11
    • Status: closed-fixed --> fixed

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks