On 2014/02/20 16:58, pelek wrote:
indeed ! I tried to open same file with Programers Notepad and file looked
exacly like I need. But when I was opening file in standard windows notepad
then I got whole CREATE TABLE code in one line!
It is problem for me, because I am trying to open same file with c# code.
Unfortunetly c# is opening the code: CREATE TABLE in one line - which is
wrong !! :( :( :(
Open it with C# code how?
Load a string or byte-stream from the file and then put it into some component? Probably the component is expecting full compatible
line truncation which is platform dependent, and you can simply fix it by the following operation on your string (after loaded from
file, but before using it in any component:
Replace all Linefeed <LF> characters ( h0A ) with full Carriage-Return+Linefeed <CRLF> characters ( h0D+h0A ) or the inter-OS string
"\n".
On most Unix Systems a single LF character is taken as a new-line specifier, and the CR is ignored silently, which has the advantage
that no matter if you use LF or CR + LF, you will see the same lines as a result. using just CR though has no real effect but can be
used in post-processing to distinguish data items, etc.
Android works a bit different and Windows takes only a full CR+LF set as a formal line-break. The advantage here is that a normal
line can contain multiple lines of information without being split down, whether you use only CR or only LF for it doesn't matter,
the line is only broken if a full CR+LF is found. This is why your lines look like 1 line when it contains multiple lines. A bonus
if you look to store multi-line data in single lines, but rather silly if you hope to display lines as lines and the originator is
of Unix descent. Most OSes encodes the " \n " character in a string line to whatever the specific OS uses as a valid line-break.
Still it is useless when the file is created on this OS only to be opened on another target OS.
I think in the case of the sqlite3.exe tool the thought is to use it the way it has always been from the Unix origins and not try to
re-encode for other OS methods since existing apps may break if that suddenly changes - but it is very easy (as explained above) to
simply fix the output for inter-OS compatibility. Note that this only applies to the tool's output, and not SQLite itself, which is
ambivalent to line-breaks.
Take Care: using "\n" might change the actual string or length thereof if your
app is multi-platform or web-based.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
