I don't use the command-line shell, but I'd definitely prefer not to see
a fundamental change in the behavior of any tool I use. The debugging
could get nasty and it's possible that someone using the tool in an
unsupervised script might not notice the problem until after it had done
some damage, or until the new, undesirable behavior had been taking
place for days/weeks.
If you make the more rational behavior a command-line option, I suspect
everyone will be happier.
Thanks,
Alex
[EMAIL PROTECTED] wrote:
In previous versions of SQLite, when the command-line shell
encountered an error, it would print an error message but
continue processing its input.
This seems wrong. In response to ticket #2045, I changed
the command-line shell so that when it is reading from a
file, it stops reading whenever it encounters an error. The
new behavior seems more rational. But it is not backwards
compatible.
So the question: Who will be adversely effected by the new
error behavior in the sqlite command-line shell? Who is
using the sqlite command-line shell in scripts in such a
way that the script will no longer work with the new
behaviors? Do I need to change the behavior back to the
way it was and provide a command-line option to provoke the
new (more rational) behavior?
For additional information:
http://www.sqlite.org/cvstrac/tktview?tn=2045
--
D. Richard Hipp <[EMAIL PROTECTED]>
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
