SQLite CLI - What is the maximum length of a command?
The CLI appears to have a limit of 4095 characters. When I .read a script containing lines longer than 4095 characters, the lines are truncated, that means that the CLI never sees the terminating semi-colon, and I see no errors being reported. - What is the maximum length of any command executable by the CLI? - Why are errors not reported?
- What is the maximum length of any command executable by the CLI?
The limit on the length of CLI input is platform-/shell-dependent and happens at a level which sqlite has no control over.
- Why are errors not reported?
Because it's not an error. sqlite only sees what your shell gives it and has no idea that you gave the shell more than that.
Edit: and while that's all very interesting, it overlooks that the question was really about input to .read, rather that input via the CLI.
I created a test file that contains one line of SQL text that is 48,918 bytes long. The file was basically this:
CREATE TEMP TABLE t1(x); INSERT INTO t1(x) VALUES('... 48890 bytes of text ...'); SELECT x, length(x) FROM t1; SELECT length(x) FROM t1;
I am able to ".read" that file and it works fine for me. Perhaps we could help you better if you were more specific about your problem:
- What version of SQLite are you using?
- Did you compile it yourself, or did somebody else compile it for you?
- What operating system are you running on?
- What is the input file that you are using?
- Specifically what commands did you try?
Version 3.33 Using 32-bit precompiled binary Windows 10 64-bit Finally tracked down the error; it is 'Error: near line 8: hex literal too big:' It occurs in an INSERT statement (originally created by SSMS/SQL Server) containing an image (read blob) column whose value is NOT wrapped in quotes. (My statement regarding truncation is a red herring.)
Does your "script" contain embedded nulls perchance? A null byte terminates a string, so if you have a "line" (by definition a sequence of non-zero bytes terminated by a line separator) containing a zero-byte somewhere within, that will terminate the resulting string despite the entire "line" being read.
If that string-terminator happens to occur within syntactically quoted text, then the next line will be read as a continuation of the syntactically quoted text until the closing quote is found.
This may result in a valid command that does not contain any errors.