|
From: Gerd W. <bir...@t-...> - 2005-07-05 19:22:09
|
Hi Xavier, Xavier Vigouroux wrote: > hi, > > I fell regularly in the situation where an erroneous SQL command is not > stored in the history. I understand the goal of this for real erroneous > command. > > However, for error relative to the loss of the connection, this couls be > stored in the SQL history. This way, I can reopen a new window to > reconnect to the DB and get the whole history. First of all I see your point. A little help for the connection loss situation might be 1. You might use Menu Session --> Reconnect 2. Add the SQL to the bookmarks. See tools popup (ctrl +t) --> add bookmark 3. Save the SQL to a file. The problem I see is to distinguish an SQLException that comes from an erroneous SQL command from one that for example results from a loss of the connection. In SQLException's API doc it say the SQLState string might tell if the database supports the XOPEN SQLstate conventions or the SQL 99 conventions. But if for example you look at PostgerSQL the getSQLStateType() method is unsupported. I can't really think of a way to find out of what category an SQLException. If you or anyone else has an idea I'd be grateful to get to know it. Gerd |
