On Fri, 27 Mar 2009 17:32:40 +0000, Simon Davies <simon.james.dav...@googlemail.com> wrote:
>2009/3/27 Francois Botha <igitur+sql...@gmail.com>: >> (my apologies if this is a duplicate) >> >>> Attachments don't make it through the mailing list, >> >> Uhm, sorry. I'm new here. I don't want to paste the SQL script in an email, >> because it contains line breaks and I don't want the formatting to change >> during email transport. >> >> Try www.vwd.co.za/sqlitedump.zip > >Confirm I get same result you are reporting. > >Don't believe it is sqlite issue tho. > >shell.c about line 704: > fprintf(p->out, "%s;\n", zSql); > >At this point zSql contains exactly the right characters. However, in >the file resulting from the printf, extra '0D' characters appear. > >Note that this only occurs with redirection on the command line. Using >".output t.sql" at the sqlite shell prompt gives the result I would >expect. > >Maybe people more familiar with micros*t internals could explain... Fossil ( http://www.fossil-scm.org/ ) had a similar anomaly, when running as CGI within Apache. In a way that's also a redirection from stdout. Windows appears to automatically add a \r (CR, 0x0D) when it sees a \n (LF, 0x0A). This caused a discrepancy between the body size as specified by the Content-length header generated by fossil and the actual number of bytes transferred into Apache. The fossil problem was solved by changing the file mode to binary. http://www.fossil-scm.org/index.html/tktview?name=c62fac40af Note: the suggested patch used the wrong parameters in the setmode() call, but the analysis and drh's implementation were correct. Perhaps the OP should file a ticket to have this corrected in the SQLite command line tool. >> regards, >> Francois > >Rgds, >Simon -- ( Kees Nuyt ) c[_] _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
