#27 Unintended Decimal Field Update

[zarac]

When editing another field in a record containing a decimal field, the decimal field value is changed.

The command below was executed when I updated only the invoice_id field; the amount was correctly showing as 75.00 before the update and incorrectly as 99999999.99 after the update. The value in the database table is now incorrect.

/* MySQL 12:52:38 */ UPDATE `items` SET `id`='14', `transact_id`='100000', `account_id`='1216', `cleared_enum`='2', `amount`='37352E3030', `account_name`='Kerns', `date`='1999-01-01', `description`='Annual Assessment', `year`='1999', `notes`='', `invoice_id`='14' WHERE `id` = '14';

[zarac]

Logged In: YES
user_id=1686728
Originator: YES

This occurs in 0.7b4 and 0.7b5. I did see this problem in the forum with a final response that it had been fixed in the latest beta; I downloaded the lastest showing, version 0.7b5, today.

[Sean Abrahams]

Logged In: YES
user_id=623529
Originator: NO

I am experiencing the same problem.

Mac OS 10.4.9, MySQL v5.0.37, CocoaMySQL v0.7b5.

This is an extremely important issue considering if someone is working on a production database and this happens, they're fucked.

I have created a screencast, but see no way to upload it to this ticket. I will see about emailing the developers directly.

[zarac]

Logged In: YES
user_id=1686728
Originator: YES

Since there hasn't been any response to this ticket, I haven't added more comments. However, I have found the bigger issue to be the same thing occurs when exporting a database. The erroroneous information sent sent to the database is also included as data for the field in the export file and results in a corrupted table when imported back in.

Sean, I hope you see this because if you try exporting, CocoaMySQL will corrupt every record in your table. Use the mysqldump command to create dumps.

[Sean Abrahams]

Logged In: YES
user_id=623529
Originator: NO

Thanks for the info Zarac and for opening this ticket.

I have emailed the developer(s) with the screencast I made of the bug as well as a link to this ticket.

I haven't heard back, but hopefully they received it and can debug the issue and release a fix.

Had I been working on a Production database it could have spelled incalculable trouble if backups weren't being performed. Luckily, I was not working on a Production database.

I believe this bug to be serious enough to warrant the removal of the package for download until a fix is released. Sure it's Beta, but the potential for damage is just too great.

Not to be unappreciative of the work of the developers of course as it is a great piece of software that truly makes my life easier. I wouldn't bother to post here for submit a screencast of the issue had I not loved the software. So, thanks CocoaMySQL guys! :)

[Nobody/Anonymous]

Logged In: NO

I've seen this related to another problem I've just encountered with a MacBook Pro OSX 10.4.9, MySQL 5.0.27 standard and CocoaMySQL 0.7b5. VARCHAR fields greater than 100 CHAR are initially displayed with an ellipsis if the column is too small. If you widen the column as much as you can it only goes so far (even if you have the space to show more) and the first 100 CHAR are displayed followed by (...) ie not a single char ellipsis but 5 char.

When you enter data, everything is fine, viewing the data in another program confirms that the data past the (...) is there, BUT, if you go back to the data in 0.7b5 and tab into the VARCHAR field and then immediately tab out, all you data past CHAR 100 is lost!! Not only that, but I then discovered EVERY decimal field was replaced with 9s, ie 9.9 to 99999.9 depending on the size.:-(

Thankfully I had backups! But I'm not going anywhere near 0.7b5 again!