Unsupported Screen Size: The viewport size is too small for the theme to render properly.

Forum Replies Created

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • in reply to: Bug Parameters Are Not Listed For My Custom Function #32569
    number_one
    Participant

    I’m using v12.12 and am not able to get stored procedure parameters to show in autocomplete.  Has there been a regression?  I’ve refreshed the object view and made sure the active database is the one with the procedure in question.

    in reply to: "user" Incorrectly Treated As Mysql Reserved Keyword #35370
    number_one
    Participant

    Peter, I’m a bit confused.  The link you provided has all of those words you mentioned (“CREATE”, “DROP”, “DELETE”, “INSERT”, “UPDATE”) listed as MySQL reserved words.

     

    But “user” (and “host” as you mentioned) are not in the list.

     

    As an aside, it’s interesting to look back through the MySQL documentation history and see how many reserved words have been added as each new version is released.  You’d think that especially for some of the more specialized features they would have added some type of MySQL prefix to prevent such a large number of fairly common words becoming reserved.  I can imagine that it has caused a fair number of problems for users that have upgraded and are using schema files without everything being escaped.  For example, MySQL 5.7 adds “GENERATED”, “VIRTUAL”, and “STORED” among others as new reserved words.

    in reply to: "user" Incorrectly Treated As Mysql Reserved Keyword #35368
    number_one
    Participant

    Thanks for looking into it.

     

    In any case I don’t think “user” should be colored as a keyword because it is a very common name for a table and/or field.  In fact the default MySQL database has a “user” table.  There is certainly a user function, but that can be distinguised by the word being directly adjacent to a parenthesis.

    number_one
    Participant

    I think practically all backup programs – including mysqldump – provide such information on top of the dump.  And in case you use multiple programs it could be useful to identify what program generated a specific dump. 

     

    This doesn’t necessarily help for the problem at hand, but running mysqldump directly does include options to not add this type of information.

     

    For example:

     

    Don’t output date that export was run:


    --skip-dump-date

    Don’t output program version. server version, host info, etc:


    --skip-comments

    And if you are wanting to only track schema changes (without data at all), in addition to adding the –no-data parameter you can also post-process the file to remove autoincrement values from the table definitions:


    mysqldump [options] | sed s/ AUTO_INCREMENT=[0-9]*//g > exported_file.sql

    Here’s a full example that won’t include anything other than the raw schema **EDITED to add quote around sed expression**


    mysqldump -u[username] -p[password] --no-data --opt --routines --triggers --skip-dump-date --skip-comments --databases [database_name] | sed 's/ AUTO_INCREMENT=[0-9]*//g' > exported_schema_file.sql

    in reply to: not parsing comments properly? #15173
    number_one
    Participant

    I mentioned this way back with the release of SQLyog 3.5

    Comments with the pound sign will no longer work because it wraps everything onto one line before parsing it as of version 3.5. Before that, it parsed each line with carriage return separately. So now the only way to reliably use comments is by enclosing a comment with /* */ type indicators.

    Very, VERY annoying for someone who uses comments frequently and would like to comment out a very long query by simply putting a pound sign in front. I don't know why it hasn't been corrected, and IMHO there is no valid reason to say that this change is “by design”.

    PLEASE, PLEASE fix this so I can stop using version 3.11

Viewing 5 posts - 1 through 5 (of 5 total)