Forum Replies Created
-
AuthorPosts
-
peterlaursen
ParticipantAfter checking details I can state that the other report I referred was not exactly this. This was another error and error message.
Are you perfectly sure that this FAQ : http://faq.webyog.co…ion-denied.html
.. does not have the explanation?
If you did not install on same machine you could have entered some details wrong, mismatched keys etc. Please double-check again.
ParticipantWe have one more report of this. For the user who reported this this is reproducible on one specific (client) machine only (and not others) and when connecting to one specific server only. We have not been able to reproduce it in our environment.
MySQL changed their SSL library (from 'openssl' to 'yassl') at some point. I don't record exactly when, but this could be related. And if it is, I think that there are good channes that latest SQLyog will work if you upgrade the server.
The key to the problem could very well be this “We have SSL Enforced on our mysql server”. Can you elaborate how? Please provide the exact configuration options (in my.cnf/my.ini)
You are welcome to create a support ticket (sending a mail to [email protected] is the easiest way)
ParticipantSorry for not replying here before.
We are not really able to read your last post. Some formatting 'screwed up' and also it seems it was truncated.
Could you please try to post again? You may use the 'code' or 'quote' option when posting in order to avoid any distortion caused by HTML formatting.
And if you have resolved this yourself, please state so.
ParticipantOK .. understood!
Do you envisage that such 'workspace' should be for a single connection or for all connections open? The latter would be easiest as it may be built on top of what we have already planned for the 'connection restore' feature.
ParticipantThere is full support of MariaDB. Also storage engines shipped with MariaDB (Aria in particular) not included with Oracle MySQL (as long as “SHOW ENGINES;” exposes availability of the particular storage engine).
Refer official MariaDB website: https://mariadb.com/…r-mariadb-aria/
Some MariaDB-specific features are not supported in GUI, but any valid SQL statement executed from the SQLyog editor will work. This includes:
* TRANSACTIONAL YES|NO parameter for the Aria engine (http://code.google.c…/detail?id=1798) (and possible also specific parameters for TokuDB added in recent MariaDB 10) etc. When creating an Aria table form SQLyog CREATE TABEL GUI interface it will be YES (becasue this is default).
* virtual columns and dynamic colums (http://code.google.c…/detail?id=1645)
ParticipantThis is an extremely old driver. Please try a recent one. 5.2.5 is latest according to http://dev.mysql.com/downloads/connector/odbc/
If you google 'Thread Didn't Exit” you will find similar reprots with old ODBC drivers.
ParticipantOK .. we will check again. Now, the only damage here is that an orphaned thread may be left running on the server. So I don't find this critical. So still it should be fixed, obviously.
The last information you provide here seems to indicate that this is a problem on the and not the as I assumed before. What version of the MySQL ODBC driver are you using?
ParticipantThe next major feature planed for SQLyog is that 'session restore' should also restore query tabs to their state when SQLyog was closed last time. Only after that we will/can consider an option to save 'restore files' at a specified time interval and not only when SQLyog closes.
If you power off your system like this accidentially, maybe I could suggest that you use an electric outlet out of reach from kids and dogs? 🙂
Jokes apart: in some parts of the world electricity supply is quite unreliable and it would make sense if such places.
ParticipantOK .. thanks for the patch. We will check this.
But please tell what SQLyog version you are using? Are you sure that such patch is required with a recent SQLyog version?
ParticipantActually it is the next major peature planned, that the 'session restore' feature should also populate query tabs to the state when SQLyog was closed.
I don't like “after a crash”. A crash is an unacceptable bug. If you experience such please report details and it will be high priority for us to fix.
ParticipantAnd if you don't want to post requested details in public, you may mail to [email protected].
Participant“Not sure what Monyog uses to decide if an instance is a slave”. It does if user has defined it as such as described in point 3) in Mahesh's reply above.
ParticipantWe tried with 5.5.13 version and it is not reproducible here.
Does this happen with one specific CSV file or all? Anyway was it possible that you could try with a more recent server?
Participant5.5.13 is still a pretty old version (5.5.33 is latest 5.5 and 5.5.13 is 2+ years old according to http://dev.mysql.com/doc/relnotes/mysql/5.5/en/). It is also same generation as the servers listed as affected in the bug report.
Anyway we will have to check if we can find the software. We did replace/rewrite some code where this may happen. But if it is a server issue that can be mended by upgrading to a more recent 5.5.x server and if our code complies with the API documentation we won't fix or 'work around'.
There are several good reasons to upgrade that server BTW (just check version notes in the link already provided). MySQL 5.5.13 still suffers from quite a lot of early InnoDB bugs in the 'InnodDB plugin' (http://dev.mysql.com/doc/innodb-plugin/1.0/en/) that replaced the previous InnoDB code (the 'built-in InnoD:cool: – as far as I remember – around New Year 2008/2009.
We also have this FAQ: http://faq.webyog.com/content/1/178/en/sqlyog-is-a-client-for-the-mysql-server-_-but-what-server-versions-are-supported.html: “For all stable/GA releases (also those listed as recommended above) it also may happen that we will not resolve an issue if an upgrade to a later version resolves the issue.”
ParticipantPlease tell:
1) The MySQL server version involved? And the platform/OS where the server is running?
2) Is this consistently reproducible on this environment? Please try to run again (use a dummy table if you want).
3) “All seem's to run o.k” also means that data were actually imported as they should?
There are similar bug reports with early MySQL 5.0 servers (before 5.0.70). Also 5.1 servers before 5.1.28 and 6.0 servers before 6.0.7 seem affected (the bug reports tell nothing about if MySQL 5.5 versions are affected):
-
AuthorPosts
