DbVisualizer 5.0.0.10 is now available

I just noticed something unusual while running some querries. If I omit a comma in my SQL - as in below: FROM: select A, B from thatDB.thatTABLE; TO: select A B from thatDB.thatTABLE; I noticed that the resultset still gets displayed - but with the data of A column displaying as B column (behaving more like an alias). Is this expected (or, is anybody experiencing the same?)? Shouldn't dbvis expect a delimiter of some sort - and terminate with an error or warning? Or, is there some setting that needs to be set in the tool properties (i.e. MySQL -> Delimited Identifiers? or Qualifiers?) to force a scenario like the above to generate a warning/error? My setup: Product: DbVisualizer Personal 5.0.0.10 Build: #1156 (2006/09/08 01:38) Java VM: Java HotSpot(TM) Client VM Java Version: 1.5.0_08-b03 Java Vendor: Sun Microsystems Inc. OS Name: Linux OS Arch: i386 OS Version: 2.6.17-1.2617.2.1.fc6 Connecting To: MySQL 4.0.18-standard-log MySQL-AB JDBC Driver mysql-connector-java-3.1.12 ( $Date: 2005-11-17 15:53:48 +0100 (Thu, 17 Nov 2005) $, $Revision$ )

Roger, what is the limit here? : /********************************************************* * Warning message * ********************************************************** * This SQL has been truncated. It is too long for * * this version of SQLinForm * *********************************************************/ Is it the length of the sqlfile or an individual sql statement? My file is 700kb, with one create index of 273kb ... (not one I do like a lot ...) BTW: open a new connection, hit SGA tab and hit Info. the debug window pops up. I understand I did not select an object to show info for but this is not were I expect the debug window to popup. thanks, Ronald.

Roger, make the commented lines dependent of oracle version being >= 9 and the sga tab is also usable for 8.1.7.4. SELECT a.SQL_TEXT, u.USERNAME, -- trunc(a.SHARABLE_MEM / 1024, 2) "SHARABLE_MEM (KB)", --trunc(a.PERSISTENT_MEM / 1024, 2) "PERSISTENT_MEM (KB)", --trunc(a.RUNTIME_MEM / 1024, 2) "RUNTIME_MEM (KB)", a.SORTS, a.VERSION_COUNT, a.LOADED_VERSIONS, a.OPEN_VERSIONS, a.USERS_OPENING, --a.FETCHES, a.EXECUTIONS, a.USERS_EXECUTING, a.LOADS, a.FIRST_LOAD_TIME, a.INVALIDATIONS, a.PARSE_CALLS, a.DISK_READS, a.BUFFER_GETS, a.ROWS_PROCESSED, a.COMMAND_TYPE, a.OPTIMIZER_MODE, a.PARSING_USER_ID, a.PARSING_SCHEMA_ID, a.KEPT_VERSIONS, rawtohex(a.ADDRESS) "ADDRESS", a.HASH_VALUE, a.MODULE, a.MODULE_HASH, a.ACTION, a.ACTION_HASH, a.SERIALIZABLE_ABORTS --a.CPU_TIME, --a.ELAPSED_TIME, --a.IS_OBSOLETE, --a.CHILD_LATCH FROM sys.v_$sqlarea a, sys.all_users u WHERE A.parsing_user_id = U.user_id; Not as informative as in 9i but better that 'invalid column name' ;-) Ronald.

Roger, if a have a table with columns a, b, c, d and I remove column b from table view with 'Column Visibility' and want to update column c in inline editor, then dbvis generates following update-script: 'update d = ? where...' instead of 'update c = ? where...'! It seems, that dbvis shifts the next columns to left, when the affected column follows the removed once. (I saw this in debug output) Regards Frank