Forum Replies Created
-
AuthorPosts
-
September 25, 2014 at 9:19 am in reply to: Group_concat( Concat(…) ) Displays Incorrectly In Grid View #35040
peterlaursen
ParticipantThanks 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.
September 22, 2014 at 1:12 pm in reply to: Group_concat( Concat(…) ) Displays Incorrectly In Grid View #35037peterlaursen
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)
September 22, 2014 at 12:51 pm in reply to: Group_concat( Concat(…) ) Displays Incorrectly In Grid View #35036peterlaursen
Participant[attachment=1968:groupconcat.jpg]
Please see attached image
September 22, 2014 at 12:49 pm in reply to: Group_concat( Concat(…) ) Displays Incorrectly In Grid View #35035peterlaursen
ParticipantThis 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-infoEnter password: ********Welcome to the MySQL monitor. Commands end with ; or g.Your MySQL connection id is 4Server 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 itsaffiliates. Other names may be trademarks of their respectiveowners.Type ‘help;’ or ‘h’ for help. Type ‘c’ to clear the current input statement.mysql> SELECT-> GROUP_CONCAT( CONCAT(title, ‘ (‘, testid, ‘)’) ORDER BY title SEPARATOR ‘, ‘) AS display-> FROM test-> GROUP BY-> category;Field 1: `display`Catalog: `def`Database: “Table: “Org_table: “Type: BLOBCollation: binary (63)Length: 1024Max_length: 134Decimals: 0Flags: BINARY+
+| display|+
+| SOME-LONG-NAME-A (1), SOME-LONG-NAME-F (6), SOME-LONG-NAME-J (10), SOME-LONG-NAME-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-NAME-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.September 22, 2014 at 12:15 pm in reply to: Group_concat( Concat(…) ) Displays Incorrectly In Grid View #35034peterlaursen
ParticipantPlease 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.
peterlaursen
ParticipantThe 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.
peterlaursen
ParticipantNo, 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.
peterlaursen
ParticipantFirst 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)
peterlaursen
ParticipantYou 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
September 9, 2014 at 12:32 pm in reply to: Change Collation To Allow Case Sensitive Seach In Varchar Fields #35029peterlaursen
ParticipantThis 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).
August 26, 2014 at 3:00 pm in reply to: Feature Request: Intelligent Defaults For Database Copy Dialog #35023peterlaursen
ParticipantThe 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.
peterlaursen
ParticipantFirst 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.
peterlaursen
ParticipantThe 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.
peterlaursen
ParticipantData 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:
peterlaursen
ParticipantYou 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.
-
AuthorPosts