Incorrect statements in SQL Commander log

I was running a script against a SQL*Server 2012 database and noticed that the DML statements indicated in the SQL Commander log didn't match those in the script. I've attached a test script to show the problem. The script executes a number of DDL/DML statements in the following order: CREATE TABLE GO (end of batch #1) INSERT UPDATE INSERT UPDATE INSERT UPDATE GO (end of batch #2) SELECT DROP TABLE GO (end of batch #3) I've also attached a screenshot showing the SQL Commander log. Note that in the second batch DbVisualizer is able to recognize that there are 6 DML statements and the row modification counts are correct, but they are all shown as INSERT statements. In the final batch the SELECT statement shows up in the log but the DROP TABLE statement does not. Is it possible to fix these issues? It's very difficult to debug scripts when the log doesn't match up.

Hi Steve, In the test script you posted, you do not have any delimiters after the statements in what you call a "batch". This means that DbVisualizer sends all those statements to the database together, and only logs the first statement. If you enable Show SQL in the log right-click area, you can see what is sent for each log entry. The statement delimiters are required if you need a log entry for each statement, as DbVisualizer has no other means to recognize that there are separate statements. Best Regards, Hans

> {quote:title=Hans Bergsten wrote:}{quote} > In the test script you posted, you do not have any delimiters after the statements in what you call a "batch". This means that DbVisualizer sends all those statements to the database together, and only logs the first statement... Yeah, that's what I had assumed at first but then when I saw that the row modification counts were correct for each DML statement I thought that you might have some way to distinguish the individual statements. After reviewing the Java docs I'm guessing that you folks must be using something like Statement.executeBatch() to submit the SQL and get back multiple update counts. Normally I prefer to use a semicolon delimiter as I find it easier to read and less prone to error, but in this case I was debugging someone else's code and found it odd that the code and the log didn't match up. Thanks for the clarification.