Logged In: YES
user_id=210714
Originator: NO

I don't remember having seen this bug report. There were other reports about a BLOB being lost on editing. Please show me the reference for other bug reports you found.

P.S. I confirm this problem.

Logged In: YES
user_id=1853116
Originator: YES

Before reporting the bug I did a search to see if it had been reported in the past. I've just done that search again and have come up with 722629 and 441689. These bugs were fixed at the time they were reported but seem to have been resurrected since.

I know for certain that the previous version we had installed also suffered from this bug but at the time we just attributed it to the same bug which nullified a BLOB entry on editing a record. Seeing that bug fixed, we assumed this one would be too but as it is obviously not the same bug thought it worth reporting.

Logged In: YES
user_id=210714
Originator: NO

You are right:
http://sourceforge.net/tracker/index.php?func=detail&aid=722629&group_id=23067&atid=377408

This seems to related to Revision 9795 (by cybot_tm, dec 2006), in which he 'removed unused code;'.

I've restored the lost lines of code in the patch below and did some testing.
When "Insert as new row" is used the BLOB value is now preserved.

In addition to the original code I added an additional check for $is_insert.

One downside of this code is that the 'protected' value is fetched even is a new file is uploaded.
It might therefore be an option to move this piece to the case 'protected' block in tbl_replace_fields.inc.php

Index: tbl_replace.php

--- tbl_replace.php (revision 12236)
+++ tbl_replace.php (working copy)
@@ -203,6 +203,15 @@

$primary_field = PMA_BS_GetPrimaryField($GLOBALS['db'], $GLOBALS['table']);

+ // Fetch the current value's of a row to use incase we have a protected field
+ // @todo possibly move to ./libraries/tbl_replace_fields.inc.php
+ if ($is_insert && $using_key && isset($me_fields_type) && is_array($me_fields_type) && isset($primary_key)) {
+ $prot_result = PMA_DBI_query('SELECT * FROM ' . PMA_backquote($table) . ' WHERE ' . $primary_key . ';');
+ $prot_row = PMA_DBI_fetch_assoc($prot_result);
+ PMA_DBI_free_result($prot_result);
+ unset($prot_result);
+ }
+
foreach ($me_fields as $key => $val) {

require './libraries/tbl_replace_fields.inc.php';

Moved to patches.

Hi Herman,
the patch works with QA_3_1 but not with the current state of trunk, because of your other patch:
http://phpmyadmin.svn.sourceforge.net/viewvc/phpmyadmin/trunk/phpMyAdmin/libraries/tbl_replace_fields.inc.php?r1=12243&r2=12242&pathrev=12243

The keys in $prot_row are not encoded so this comparison:
if (! empty($prot_row[$key])) {
finds nothing in $prot_row because at this point, $key is encoded.

Maybe a little loop after setting $prot_row to encode all keys?

Marc,

It seems that all that is required is the extra single line patch below.

Herman

Index: libraries/tbl_replace_fields.inc.php

--- libraries/tbl_replace_fields.inc.php (revision 12244)
+++ libraries/tbl_replace_fields.inc.php (working copy)
@@ -96,7 +96,7 @@
// garvin: when in UPDATE mode, do not alter field's contents. When in INSERT
// mode, insert empty field because no values were submitted. If protected
// blobs where set, insert original fields content.
- if (! empty($prot_row[$key])) {
+ if (! empty($prot_row[$me_fields_name[$key]])) {
$val = '0x' . bin2hex($prot_row[$me_fields_name[$key]]);
} else {
$val = '';

Merged in subversion, thanks.