Easily find issues by searching: #<Issue ID>
Example: #1832
Easily find members by searching in: <username>, <first name> and <last name>.
Example: Search smith, will return results smith and adamsmith
Mainly following the steps described in #7538, that would be:
1. connect to a server using the default db (e.g. \connect my-server)
2. connect to the same server on a different db (e.g. \connect my-server -d different-db -k s2)
3. go to menu DBA Tools > My-DB-Type > Session Manager, select the connection from step 2 and kill it
4. go back to the FS tab and enter the session command (\session)
5. enter the session command once again
a. The Status column after step 4 displays Connected for the second connection, and nothing for the Database column, it should display the same information as after step 5, that is Closed, and the name of the database respectively.
b. Both after step 4 and step 5, the GUI status displayed in the FluidShell tab remains Connected to server-X / db-Y which in a way is misleading as one could not execute a query on the server in the current state.
Tested using ADStudio 12 RC 23 on a MySQL server in Ubuntu 12.04.
The scenario is exemplified in the attached screenshot fs-session-connection-killed.png.
This is caused because the JDBC Connection.isClosed() will return true even if a connection is closed, until a failed query is executed. I solved this problem by calling getCurrentDatabase(), and then calling Connection.isClosed(). SVN #29809
Verfied using ADStudio 12.0.0 on Ubuntu 12.10 using a MySQL server.
a. After step 4 now the Status column display the expected info (i.e., Closed), however the Database column is still empty, it should display the name of the DB as after step 5.
b. No change on the GUI status, it remains Conected to server-X / db-Y all the time.
Verfied using ADStudio 12.0.0 on Ubuntu 12.10 using a MySQL server.
a. After step 4 now the Status column display the expected info (i.e., Closed), however the Database column is still empty, it should display the name of the DB as after step 5.
b. No change on the GUI status, it remains Conected to server-X / db-Y all the time.
> a. After step 4 now the Status column display the expected info (i.e., Closed), however the Database column is still empty, it should display the name of the DB as after step 5.
Fixed.
> b. No change on the GUI status, it remains Conected to server-X / db-Y all the time.
Discussed with Niels, the GUI status will remain 'Connected ...' until a command which executes SQL statement(s) gets executed; e.g. \sqlexport, \session, etc. After such a command is executed, the GUI status should change to 'Disconnected'.
> a. After step 4 now the Status column display the expected info (i.e., Closed), however the Database column is still empty, it should display the name of the DB as after step 5.
Fixed.
> b. No change on the GUI status, it remains Conected to server-X / db-Y all the time.
Discussed with Niels, the GUI status will remain 'Connected ...' until a command which executes SQL statement(s) gets executed; e.g. \sqlexport, \session, etc. After such a command is executed, the GUI status should change to 'Disconnected'.
Communications link failure Error message is printed; if executing it after, an Exception message go: Connection to RDBMS is already closed is printed.select 123, then press Enter, then type in \go, and Enter again - first case appears
Communications link failure Error message is printed; if executing it after, an Exception message go: Connection to RDBMS is already closed is printed.select 123, then press Enter, then type in \go, and Enter again - first case appearsSadly, we can't produce that error pattern because we don't execute any statement before we execute the SQL Buffer. So, when you execute \go, then we try to execute the sqlbuffer and the driver throws that exception and we display it. Once the driver throws that exception then the driver knows that the connection is closed (although it didn't know previously when it was executing the first time).
I agree that it would be better to display the errors as you described, but we can't because we don't have full control over the SQLConnection and its behavior, and this is how it works.
Sadly, we can't produce that error pattern because we don't execute any statement before we execute the SQL Buffer. So, when you execute \go, then we try to execute the sqlbuffer and the driver throws that exception and we display it. Once the driver throws that exception then the driver knows that the connection is closed (although it didn't know previously when it was executing the first time).
I agree that it would be better to display the errors as you described, but we can't because we don't have full control over the SQLConnection and its behavior, and this is how it works.
> I agree that it would be better to display the errors as you described, but we can't because we don't have full control over the SQLConnection and its behavior, and this is how it works.
OK.
However, as in ADStudio 12.0.5, there's a regression compared to previous versions, the status mentioned at (b) no longer changes to "Disconnected" after running the first DB-related command. Reopening for this reason.
> I agree that it would be better to display the errors as you described, but we can't because we don't have full control over the SQLConnection and its behavior, and this is how it works.
OK.
However, as in ADStudio 12.0.5, there's a regression compared to previous versions, the status mentioned at (b) no longer changes to "Disconnected" after running the first DB-related command. Reopening for this reason.
Hi Niels,
You might want to take a look at the SVN r29963 merge you did on TerminalPanelView.java. SVN r29963 removed fix for issues #7820 and #7856.
Hi Niels,
You might want to take a look at the SVN r29963 merge you did on TerminalPanelView.java. SVN r29963 removed fix for issues #7820 and #7856.
Fixes to #7820 and #7856 where made to the Trunk on 10/25/2012 - Thursday
Trunk was branched to 12.0 on 10/28/2012 - 11:34 AM - Sunday
On 10/29 Larion provided a fix which I checked in to 12.0 branch and merged to Trunk, which he had from 10/24. It missed this merging.
Fixes to #7820 and #7856 where made to the Trunk on 10/25/2012 - Thursday
Trunk was branched to 12.0 on 10/28/2012 - 11:34 AM - Sunday
On 10/29 Larion provided a fix which I checked in to 12.0 branch and merged to Trunk, which he had from 10/24. It missed this merging.
Verified using ADStudio 12.0.6, the status now changes to Disconnected after the first executed DB-related cmd.
Closed.
Verified using ADStudio 12.0.6, the status now changes to Disconnected after the first executed DB-related cmd.
Closed.
Issue #7820 |
| Closed |
| Fixed |
| Resolved |
Completion |
| No due date |
| Fixed Build trunk/29920 |
| No time estimate |
1 issue link |
relates to #7904
Issue #7904Executing inline SQL on a Closed/Killed connection |
This is caused because the JDBC Connection.isClosed() will return true even if a connection is closed, until a failed query is executed. I solved this problem by calling getCurrentDatabase(), and then calling Connection.isClosed(). SVN #29809