Okay, got answer by myself. It is not relevant to any TM1 version. It is just how mysql workbench produce SQL in its editor.
How mysql workbench add invisible char into the end of each line (only LF, which is Unix way)
- 1.PNG (2.64 KiB) Viewed 4225 times
After copying same sql into notepad++, how notepad++ display the end of each line (CR+LF, which is windows way)
- 2.PNG (2.72 KiB) Viewed 4225 times
And the sql window in TI only recognize the common window way of displaying end of each line, which is CR+LF. If you copy sql directly from workbench into TI window, at first, you won't see any problem and that sql will be only displayed into one line, (That is where I found the difference from and trace out the root cause) but once you reboot your server, TI would automatically truncate the whole sql at the first place of LF. That caused the failure.
For anyone who is not familiar with CR or LF. read this,
CR an LF are control characters, respectively coded 0x0D (13 decimal) and 0x0A (10 decimal).
They are used to mark a line break in text file. A you indicated, Windows uses two characters the CR LF sequence; Unix only uses LF and MacIntosh CR.
An apocryphal historical perspective
As indicated by Peter, CR = Carriage Return and LF = Line Feed, two expressions which have their roots in the old typewriters / TTY. LF moved the paper up (but kept the horizontal position identical) and CR brought back the "carriage" so that the next character typed would be at the leftmost position on the paper (but on the same line). CR+LF was doing both, i.e. preparing to type a new line. As time went by the physical semantics of the codes were not applicable, and as memory and floppy disk space was at a premium, some OS designers decided to only use one of the characters, they just didn't communicate very well with one another
Most modern text editors and text-oriented application offer options/settings etc. that allow the automatic detection of the file's end-of-line convention and to display it accordingly.
