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

Forum Replies Created

Viewing 15 posts - 226 through 240 (of 7,398 total)
  • Author
    Posts
  • in reply to: Group_concat( Concat(…) ) Displays Incorrectly In Grid View #35040
    peterlaursen
    Participant

    Thanks for the detailed explanation (that I do not fully understand yet).

     

    Can you please specify if you think you found a bug/an oddity with MySQL or with SQlyog.  This is not clear to me. If you think it is with SQLyog, please try to clarify what the exact issue is.

    in reply to: Group_concat( Concat(…) ) Displays Incorrectly In Grid View #35037
    peterlaursen
    Participant

    [attachment=1969:width.jpg]

     

    Besides you may increase the cell-width with the mouse, so that all data display. SQLyog wll even remember the width setting for that particular query (also after a program restart)  

    in reply to: Group_concat( Concat(…) ) Displays Incorrectly In Grid View #35036
    peterlaursen
    Participant

    [attachment=1968:groupconcat.jpg]

     

    Please see attached image

    in reply to: Group_concat( Concat(…) ) Displays Incorrectly In Grid View #35035
    peterlaursen
    Participant

    This is expected behaviour. Try cmmand line client  with the –column-type-info option

     

    C:Program FilesMySQLMySQL Server 5.6bin>mysql -uroot -p –port=3308 –column

    -type-info

    Enter password: ********

    Welcome to the MySQL monitor.  Commands end with ; or g.

    Your MySQL connection id is 4

    Server version: 5.1.73-community MySQL Community Server (GPL)

     

    Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved.

     

    Oracle is a registered trademark of Oracle Corporation and/or its

    affiliates. Other names may be trademarks of their respective

    owners.

     

    Type ‘help;’ or ‘h’ for help. Type ‘c’ to clear the current input statement.

     

    mysql> SELECT

        ->     GROUP_CONCAT( CONCAT(title, ‘ (‘, testid, ‘)’) ORDER BY title SEPARAT

    OR ‘, ‘) AS display

        -> FROM test

        -> GROUP BY

        ->     category;

     

    Field   1:  `display`

    Catalog:    `def`

    Database:   “

    Table:      “

    Org_table:  “

    Type:       BLOB

    Collation:  binary (63)

    Length:     1024

    Max_length: 134

    Decimals:   0

    Flags:      BINARY

     

     

    +



    +

    | display

                                                             |

    +



    +

    | SOME-LONG-NAME-A (1), SOME-LONG-NAME-F (6), SOME-LONG-NAME-J (10), SOME-LONG-N

    AME-M (13), SOME-LONG-NAME-O (15), SOME-LONG-NAME-Q (17) |

    | SOME-LONG-NAME-B (2), SOME-LONG-NAME-G (7), SOME-LONG-NAME-K (11), SOME-LONG-N

    AME-N (14), SOME-LONG-NAME-P (16)                        |

    | SOME-LONG-NAME-C (3), SOME-LONG-NAME-H (8), SOME-LONG-NAME-L (12)

                                                             |

    | SOME-LONG-NAME-D (4), SOME-LONG-NAME-I (9)

                                                             |

    | SOME-LONG-NAME-E (5)

                                                             |

    +



    +

    5 rows in set (0.00 sec)

     

    mysql>

     

     

    Note that metadata read “Type: BLOB” and “Length: 1024” (I checked with multple server versions and it is the same from MySQL 5.1 at least).

     

     

     

    With BLOB and TEXT data SQLog will display full data in the BLOB viewer (click on the button in the cell to open Blob Viewer). 

     

    I have added a reference to this discussion in our issuetracker here https://code.google.com/p/sqlyog/issues/detail?id=919. It has listed other considerations about when we should and should not use the BLOB viewer.  However we are told by the server here that the result type is 1000 bytes long. Fully padded with characters it would be too long for display in the GRID. Anyway metadata also tell “Max_length: 134”. So we culd use that in combinaton with the user setting proposed in the issue tracker. Curently we don’t. Any *BLOB and *TEXT type (not only plain BLOBs and TEXTs but also TINYBLOB, MEDIUMTEXT etc.) opens in the BLOB viewer.

     

     

    I remember that such cases were actually one of the resons why we introduced TEXT-mode in SQLyog.

    in reply to: Group_concat( Concat(…) ) Displays Incorrectly In Grid View #35034
    peterlaursen
    Participant

    Please tell your server version.  This may be an issue with metadata returned from the server (a result set is both data and metadata). We will use the metadata for allocating a memory buffer. 

    in reply to: Export As Options – Feature Request #35033
    peterlaursen
    Participant

    The exprimental JSON support in MySQL is (accordng to http://blog.ulf-wendel.de/2013/mysql-5-7-sql-functions-for-json-udf/) available in ‘labs’ builds only. They are not merged into the main 5.7 tree and it is not known whether they will be. They may go into next release cycle only (5.8) or may never be.

     

    Of course data series from a MySQL table (or result set)  in a JSON format could be useful in lots of context for users even if the MySQL server does not handle it.  But I don’t think we wll repeat the mistake we did with XML 8 years ago: formatting the data stream in a way that is not really compatible with anythng else.

    in reply to: Export As Options – Feature Request #35032
    peterlaursen
    Participant

    No,  we haver never discussed that as far as I remember. But it is an OK request IMO. But I am not so familiar wiht SN that I  know how well-defined “export as JSON’ would be. ‘Export as XML’ is not. Some choices may need to be done.

     

    We have an XML export opton currently (but not very useful due to limitations listed here: https://code.google.com/p/sqlyog/issues/detail?id=716)

     

     

     

    I have seen some JSON options added (I think experimentally in the current MySQl 5.7 development tree) . For both XML and JSON we should be compatible with MySQL and tools for same. We will update here after discussion. But it could take a few weeks.

    in reply to: Table Fragmentation Feature Suggestion #35031
    peterlaursen
    Participant

    First link should be 

     

    http://blog.webyog.com/2011/12/16/monitor-your-mysql-servers-like-never-before-use-csos/

     

    (it was not inserted as a clickable link in previous post)

    in reply to: Table Fragmentation Feature Suggestion #35030
    peterlaursen
    Participant

    You can integrate this into MONog yourself using the ‘Custom SQL Object’ feature.

     

     

    links:

    htlp://blog.webyog.com/2011/12/16/monitor-your-mysql-servers-like-never-before-use-csos/

    http://blog.webyog.com/2011/12/19/how-to-add-a-simple-custom-object-in-monyog/

     

    and two documentation pages:

    https://static.webyog.com/docs/MONyog/MONyog_MySQL_Monitor_Custom_SQL_Objects.htm

    https://static.webyog.com/docs/MONyog/Add_Custom_SQL_Objects_MONyog_Monitor_Advisor.htm

    peterlaursen
    Participant

    This is not an issue with SQLyog.  This is how the server behaves.

    An ALTER TABLE statement changing the charset and/or collation of a table as such ony deines a rul for new clumns adn do not change anything as regards existing columns. 

    Since your are pasting from the ‘mysql’ command line client you probably also realize this (?).

     

     

    You have 2 options.

    1) Execute an ALTER TABLE statement where charset/collation is changed at the column level. In SQLyo ALTE TABLE dialog there is a checkbox on upper right corner reading “Hide language options”.  If you unheck this checkbox, two more columns will become visible in the GUI. You will be able to define charset and collaton at the column level. Please try it and please read in HISTORY tab wat the generated statement looks like.

    2) Alternatively you can always use a COLLATE-clause in a select query (refer http://dev.mysql.com/doc/refman/5.0/en/charset-collate.html).

    peterlaursen
    Participant

    The problem is that, what is smart for one user, may not be for another, but could be an annoyance instead. And what if you have not 2, but 5, connections open? What should the logic be?

     

    I personally think we will have to point thumbs down on this.

    in reply to: Recovering From A Crashed Database #35027
    peterlaursen
    Participant

    First of all, this is a support question for the MySQL server.  In principle we support our own programs (SQLyog and MONyog) and not the MySQL server or any other program from Oracle (or any other vendor). We also do not provide any consultacy services for resolving such problems.

     

    The .frm files do not contain any data. The only contain table definitions and similar. How data are stored depends on the storage engine used (MyISAM or InnoDB – find details here http://dev.mysql.com/doc/refman/5.5/en/storage-engines.html).

     

    It is very unlikely you can solve this problem by just copying files around. 

     

    First of all you should ensure a copy of the complete ‘datadir’ (MySQL data folder) before doing anything else. 

     

    Also the term ‘crash’ can mean a lot of things. InnoDB has automatic crash- recovery (that will work in 99.99% of cases at least).  So I assume that you are using MyISAM? In that case please refer mySQL documentation http://dev.mysql.com/doc/refman/5.5/en/myisam-repair.html.

     

    But basically you should ask this another place, such as the MySQL Forums at http://forums.mysql.com/ for instance. And if somebody should be able to help you, you will have to be much more specific about the problem. What exactly hapenned. And what is now the problem? Will the server not start for instance? Also check the MySQL error log (http://dev.mysql.com/doc/refman/5.5/en/error-log.html) for details.

    in reply to: Automation Of Sql Query #35020
    peterlaursen
    Participant

    The is an “SQL Scheduler and Reporting Tool” (in the ‘powertools’ menu), but it will deliver query results as HTML-formatted mail. With the same tool you may schedule a SELECT INTO OUTFILE -query generating a CSV file.  But note that  SELECT INTO OUTFILE in MySQL has no LOCAL option so the file will be saved on the server machine. Refer MySQL documentaton http://dev.mysql.com/doc/refman/5.5/en/select-into.html.

     

    We have a request already for client-side generation fof CSV (and other file formats) from this tool in our issuetracker at https://code.google.com/p/sqlyog/issues/detail?id=1696.  But it is currently not possible and it is also not planned for near future.

    in reply to: Odbc Syncing With Mysql? #35019
    peterlaursen
    Participant

    Data Sync in SQLyog only works with MySQL as both source and target. You can sync content of one MySQL database with another MySQL database (on same or different servers).

     

    We also have an ‘import external data’ tool (also from the ‘powertools’ menu) making use of ODBC. It has a lot of settings and it may be useful for your needs. You can INSERT new data rows into MySQL and UPDATE existing ones based on what happens on the ODBC source.  But DELETE from the MySQL target is not possible with this tool.

     

    The documentation has a lengthy paragraph on the ‘import external data’ tool.  Find it in help .. help -menu or online here: 

    https://www.webyog.com/webyog/sqlyogDocs

    in reply to: Bug: Copy Data From Toolbar Does Not Work #35016
    peterlaursen
    Participant

    You will find the same optons in the database and table menus as well as database and table context menus in the Object browser.  They are not affected.  Please use those untill next release where this will be fixed.

Viewing 15 posts - 226 through 240 (of 7,398 total)