bug ?

table data tab
click on field --> set focus
paste data like this:
'xxxxxxxxxxxxxxxxxxxxxxxxxxxx
yyyyyyyyyyyyyyyyyy'

linefeed inside !

save, i.e, set focus somewhere else.



See what is in that field, only 'xxxxxxxxxxxxxxxxxxxxxxxxxxxx'
part !

That's no bug: table data is not supposed to be in multiple lines.

If you need a linefeed in your data (offending various database rules, btw), you can add an encased linefeed code in the single line of data. Examples (depending on the language which later parses the data) could be

,

or (for HTML)

<br />

.

Forum swallowed the entities " & # 0 1 0 ; " and " & # 0 1 3 ; " (remove the spaces)

IMO, character fields are supposed to contain characters; LF is nothing special. "offending various database rules" ? cite one or two.

Line feeds are very ok in text columns. But BubikolRamios, I guess you did only check what the grid displays in that cell - which is GUI wise forced to be one line per cell. If you edit the relevant cell with F2 you will see the line feed again.

Nope.

table data tab
click on field --> set focus
paste data like this:
'xxxxxxxxxxxxxxxxxxxxxxxxxxxx
yyyyyyyyyyyyyyyyyy'

linefeed inside !

save, i.e, set focus somewhere else.



See what is in that field (PRES F2), only 'xxxxxxxxxxxxxxxxxxxxxxxxxxxx'
part !

If you paste text with line feed into F2 window then it is OK.

jfalch,

we may venture into philosophic waters here ...

it has nothing to do with 'characters', but meaningful 'data':
a data field content which requires a linefeed represents two (or more) singular entities. As such, that offends the First Normal Form (and as result may also offend the Second Nominal Form, depending on data used).

Just because one can actually include line feeds (or an appropriate encased character) does not mean that it is valid per definition, especially when holding up- or downgrade-ability in mind. A stricter future version of MySQL could render totally chaotic results; even if the user switches to a different OS now *could* result in loss of data integrity as various OS use different LF entities). Encased LF chars also hold a secondary danger: dumping data to a CSV will likely end up in disaster as for example the semicolon mostly used with an encasement may be interpreted as field end designator ...

Using data fields in an inappropriate way in the end leads to failure or loss, or at least results in a massive increase in service time and bug tracking. Example: every website owner that is 'forced' to support the Microsoft IE browsers encounters such a problem nearly every day. IE breaks everything because MS coders believe that they do not have to fully stick to W3C guidelines. Result: umpteen 'dirty' browser fixes and numerous browser hacks to merely achieve what all other browsers render (more or less, sic!) correctly.

Don't get me wrong, I am *not* saying that BubikolRamios is committing a crime or is a total nutface, I am only pointing out that utilizing certain 'undocumented features' will most probably backfire sooner or later.

point beeing: one would expect , if same data pasted into F2 window and that sticks to db, same would happen pasting it direct to table cell in data tab (regardless you don't see it all)

Pasting without F2 does not cut or break at line feeds here. The following UPDATE in the SQL log says:

UPDATE `editors` SET `name`='xxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\nyyyyyyyyyyyyyyyyyy' WHERE `id`...;

Then, when pressing F2 on that cell shows the perfect linefeed.

Do not know. Tested it again.It cuts it.
Copying two lines from windows notepad.

yeah right, log:

UPDATE `fixed_data_fruits_detail` SET `op`='xxxxxxxxxxxxxxxxxxxxxxxxxxxx' WHERE ...;

Hm, can't believe then your clipboard contains the linefeed when I see that UPDATE...

Turns out that the thing works wrong only if some text already in that field.
See video that you got on your mail.

The text is cut off the second you hit paste.

Your video per mail reveals you have not just focused the cell, it is indeed in editing mode, with the one-line edit box. This Windows control is not able to get line feeds. You need to press F2 again, or the right "..." button in order to start the multi-line editor. Or, just focus the cell without editing it, press paste and you're done.

Or, just focus the cell without editing it, press paste and you're done.

Thanks, I would not think of that in years, the thing looked like focused & disabled to me, as it does not allow to type anything into it at that state.

In your video, the first situation allows editing in the one-line editor, the second one not as the cell is just focused but pasting also works here, for conveniance reasons.

I can sympathise with Bubikol.

I had copied a multiline value from one cell to another, and had click the destination cell twice so I had a cursor to paste to. I didn't suspect that only the first line had copied across until my application started throwing errors :)

It's definitely something users need to look out for.

Well, this is how the Windows edit control works. And this is why such cells have a "..." button on it, which calls the multiline popup editor. Well, you can even paste without being in edit mode at all, as said above.