When you edit existing row and want to insert is as new
row you lose content of protected fields (eg. BLOB).
Logged In: YES
what are your settings for $cfg['ShowBlob'], $cfg
['ProtectBinary'] and $cfg['UploadDir']?
I cannot reproduce this behaviour with my settings (TRUE,
never mind. I can now reproduce this, I misinterpreted the
issue. I'm looking into this, but it's rather difficult to use
binary data from a textfield to create a new row. I'm trying to
use the field_prev values for that. I have a halfway-through
solution handy, but this needs more work...
Logged In: YES
When (FALSE, 'blob', anything), the BLOB isn't displayed,
isn't posted and isn't inserted. There are two solutions for
1. Add blob as hidden input to form even when protected.
2. Get BLOB when inserting new row.
This second one is IMHO correct, but I just didn't have time
to write it so I posted this bug ... and I forgot to assign
it to myself. But feel free to code it :-)
I implemented the second one because I agree to think it's
not a good idea to transmit too much binary data for POST, if
we already have content in the DB.
There are serious issues remaining, when ProtectBinary is
set to FALSE. I played around the whole day trying to debug
whats happening because fields get updated even though
they were not changed. I found out, that there are more than
the normal special chars around, that get converted when
submitting binary data in a textarea. I worked around some
things by using bin2hex() and also reversing the \0, \r, \n, ...
replacements. With some files this does the trick, but with
others there are some special characters remaining.
Like, all xA0h chars get converted to x20h when submitting
the textarea. But this change cannot be reversed by changing
x20h to xA0h because x20h is a value which can also get
So I leave that case open, I don't think that HTML forms were
designed for that, so it's not our fault :)
I guess ProtectBinary should in any case only be set to
FALSE if you want to store ASCII data in a blob and editing
Enough of my mumbling: This bug has been fixed in CVS. :)
I tested it, but it only inserts 8 bytes of random (not
random, but not related to the content :-) data. When I
changed query you generate (it was IMHO correct, but it
didn't work :-)) to SELECT * ... it now works :-)
Alexander M. Turek