Start a new topic

Make new SQL Commander windows with auto-generated DDL closeable without confirmation

When DbVisualizer is asked to generate DDL and load it into a new SQL Commander window, I would like to have it do 2 things:

  1. Add a comment line at the beginning with a timestamp, the connection name and the identifying information about the object (table, view, stored procedure, etc) being described
  2. Mark the new SQL Commander window as "clean" rather than "dirty", so it can be closed without confirmation
I often open DDL for reference, and the easiest way is to use a new SQL Commander window. Then I have these windows hanging around, and when I close them I have to confirm the action but I don't necessarily remember whether I made any changes that I want to save.

I know that technically it's an unsaved buffer the instant DbVis opens it, but since it's an auto-generated unsaved buffer, as long as I don't type into it, it should be closeable without confirmation.

Hi Charles,

I  agree on the clean argument and will open a ticket for it. 

I am however wondering what a comment would add that is not already included in the generated output? Any associated database connection, database, and schema are also set in the SQL Commander settings.



Hi Charles,

Just to inform you that we have just released a new beta version of the upcoming DbVisualizer 11.0 with a new option, "Set Modified State when Scripting" in Tools->Tool Properties  under the General / SQL Commander category. Uncheck if to keep auto created SQL Commander tabs initially clean.

Would be great if you can give it a test to verify that it works properly.



Cool! Now that's what I call "fast turnaround!"


For the record, the rest of this applies only to the paid version of the software where you can have more than one Sql Cmdr window...


The feature works as intended, but I noticed that it allows (as it did before) Ctrl+Z to "undo" the insertion of the SQL. If you do that you're left with an empty buffer that demands to be saved before it can be closed! I guess before this new feature, that behavior kind of made sense (the buffer was dirty so undoing the insert left it dirty), but with this change in effect you're undo-ing a clean buffer to get an empty file, which logically should be clean, too.


If it were up to me, I would disallow the initial undo completely - it's counter-intuitive and it really serves no purpose (though this is not true for the free version).


Going farther, you might want to think about *always* making an empty buffer close-able without confirmation (I'll let you decide whether it should be marked "dirty" or "clean"). I should *never* be asked to save an empty Sql Cmdr tab, no matter *how* it got to that state. Now I'll admit that a dirty, empty buffer has associated "undo/redo" data, so you could make a case for confirming that the user wants to throw that away, but truthfully, DbVis doesn't *say* that's why it's asking; all a user sees is "do you want to create an empty file on your hard drive?". Alternatively, you could change the "close" message to "Do you want to close this buffer and lose the list of changes you made to get it this way?", but I'd doubt you'd get a lot of "yes!" answers to that question :)


Last thing: I'm not sure how difficult it would be for the Sql Cmdr tab to act like a regular text editor and restore the clean/dirty flag to "clean" after a tab has been undone (undo-ed?) to its last-saved state. I have to admit I sometimes use that ability in Sublime to figure out where I am in the undo/redo list; but I'm also kind of a fanatic :)

Two more thoughts:

A) You might consider naming the new Sql Cmdr buffer, perhaps with the table name, a SQL extension, and maybe a prefix like "autocreate-" (effectively, "autocreate-TABLE_NAME.sql)

B) I never responded to your previous comment:

>>I am however wondering what a comment would add that is not already included in the generated output? Any associated database connection, database, and schema are also set in the SQL Commander settings.

I'm not sure what you mean by "are also set in the SQL Commander settings," but I was just thinking about the text itself. If I generate a table's DDL and then copy that text and paste it outside of DbVis, it loses all the context DbVis gave it. That's why a comment with that information, which would travel *with* the text, would be useful. The way my company works, it's especially useful to know what the source connection was (Dev, Test or Prod); with a automatically generated comment, I could simply generate all DDL for each of the 3 connections into a single file.

Not only that, but if that info becomes part of the text, I could identify the source table even if I change the connection. For example, generate the DDL for Dev connection, change the Database Connection in the SQL Commander to Test and execute the DDL, but retain the knowledge of which connection was used to generate it.

Login or Signup to post a comment