>* On the other hand, we control the ij application, and we may want to improve it.
>Documenting this problematic behavior like suggested may be enough, but it would
>also be possible to abort the 'quit;' call with an exception saying:
Depends on how much of derby specific code you want to put in ij, Jorgen.
I must admit I was surprised at seeing the derby system shutdown being attempted
when we do a quit itself.
My impression about ij was ij is a general jdbc front end tool. It can be used with any database
that supports a jdbc driver. This shutdown attempt with use to any other database (different
jdbc url) will surely fail. Well maybe that is why we ignore the SQLExceptions upon doing
Adding more and more derby specific code to ij, makes ij more and more a
derby specific tool and lesser and lesser a general jdbc interface supporting front-end.
For now I will lower the severity of the issue. I think we can take it from there.
I will also leave the issue open.