distal-attribute
distal-attribute
distal-attribute
distal-attribute

bug ?

BubikolRamios posted 2 years ago in General
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 !
TTSneko posted 2 years ago
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 />

.
TTSneko posted 2 years ago
Forum swallowed the entities " & # 0 1 0 ; " and " & # 0 1 3 ; " (remove the spaces)
jfalch posted 2 years ago
IMO, character fields are supposed to contain characters; LF is nothing special. "offending various database rules" ? cite one or two.
ansgar posted 2 years ago
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.

BubikolRamios posted 2 years ago
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.

TTSneko posted 2 years ago
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.
BubikolRamios posted 2 years ago
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)
ansgar posted 2 years ago
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.
BubikolRamios posted 2 years ago
Do not know. Tested it again.It cuts it.
Copying two lines from windows notepad.

BubikolRamios posted 2 years ago
yeah right, log:

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

ansgar posted 2 years ago
Hm, can't believe then your clipboard contains the linefeed when I see that UPDATE...
BubikolRamios posted 2 years ago
Turns out that the thing works wrong only if some text already in that field.
See video that you got on your mail.

BubikolRamios posted 2 years ago
The text is cut off the second you hit paste.
ansgar posted 2 years ago
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.

BubikolRamios posted 2 years ago

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.
ansgar posted 2 years ago
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.
microUgly posted 2 years ago
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.
ansgar posted 2 years ago
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.

Please login to leave a reply, or register at first.