[peterlaursen]

Ok .. we will check. But it may be data specific. You write “Error reproduced on 2x Win 8.1 systems“.  But with the same file or not? If it is one specific file can you share it (privately, of course) if we need it? Also it may be reproducible only with specific delimiters.  Can you please attach a screenshot of your settings here? 

 

Anyway we will check the dump and update here if we need more details.

[peterlaursen]

I cannot reproduce. What  is the SQLyog version you are using? We fixed some tokenizer issus that could result in this. But it is years ago now.

[peterlaursen]

I have added the request here: https://code.google.com/p/sqlyog/issues/detail?id=2062

[peterlaursen]

@Mitch .. we have a problem here. it is not possble to specify SSL-options in a CREATE USER statement. Further we cannot take it for granted that server is not running with NO_AUTO_CREATE_USER sql_mode, and for same reason we cannot replace CREATE USER with GRANT USAGE.

 

I posted this bug report to MySQl: http://bugs.mysql.com/bug.php?id=74685, and as long as CREATE USER ..REQUIRE .. is not supported syntax, I don’t think we can support this.

[peterlaursen]

I am sorry, but I am not able to understand/recognize the context. Where are we exactly in the program interface?

[peterlaursen]

“This issue came together with the SQLyog sessions”.  This is also what we suspect. But we have not yet identified the conditions triggering it.  We have one more simliar report (this one on a Wine beta version).

[peterlaursen]

Not only with Data Sync, but also with ‘copy database’ (from the database menu/context menu) you can do it.

 

But we have no plans to import not anything else but MySQL.  Please refer this FAQ:  http://faq.webyog.com/content/32/65/en/what-kind-of-databases-does-sqlyog-support.html

[peterlaursen]

This is not possible. and we also have no plans to introduce it in MONyog. Maybe you could have a look at another Monitoring tool of ours: Sealion: https://sealion.com/. 

 

MONyog is intended for monitoring MySQL (with a few additional monitors for the underlying OS, if it is Linux). We have no plans to expand MONyog into a tool for OS monitoring, file system monitoring etc. With Sealion you can monitor anything based on a single-line command. This is the orignal blog announcing Sealion: http://blog.sealion.com/post/62987598857/why-did-we-create-sealion

[peterlaursen]

Let me add that it is a common (and dangerous) misunderstanding that a user with GRANTS with SSL option will automatically create an encrypted connection, when connecting. He will not (quote: “the client must specify either the –ssl-ca option, or all three of the –ssl-ca, –ssl-key, and –ssl-cert options”). 

 

This is a problem that is re-invented at bugs.mysql.com almost every month.  Somebody observes that a connection by a user with some SSL option -GRANTS is not encrypted and reports it as a bug. It is equally routinedly turned down as ‘not a bug’ with reference to the documentation detals, I pasted above.

[peterlaursen]

well  .. we can only execute a query from inside a query tab (or – when saved to a file –  from menu .. tools .. execute SQL script but in that case the results from SELECT and SHOW statements do not display).

 

A displayed result set in SQLyog is a ‘child’ of the Query tab that holds the query and a result set cannot display otherwise. What we could do is to add a context menu to favorites “open in new query tab and execute” or similar. However I think wtih session restore of recent versions there is another solution.  Just have a (or more) saved session with the queries you execute routinedly.

[peterlaursen]

In MySQL SSL is specifed at connection leve and not (necessarly) at user level.

 

http://dev.mysql.com/doc/refman/5.6/en/grant.html

 

• REQUIRE NONE indicates that the account has no SSL or X509 requirements. This is the default if no SSL-related REQUIRE options are specified. Unencrypted connections are permitted if the user name and password are valid. However, encrypted connections can also be used, at the client’s option, if the client has the proper certificate and key files. That is, the client need not specify any SSL command options, in which case the connection will be unencrypted. To use an encrypted connection, the client must specify either the –ssl-ca option, or all three of the –ssl-ca, –ssl-key, and –ssl-cert options.

.. in other words  user created with REQUIRE SLL may still connect an unencrytped way

 

.. and the syntax description at http://dev.mysql.com/doc/refman/5.6/en/grant.html:

 

[REQUIRE {NONE | ssl_option [[AND] ssl_option] …}]

and 

ssl_option:

SSL

| X509

| CIPHER ‘cipher‘

| ISSUER ‘issuer‘

| SUBJECT ‘subject‘

.. what means that a user may have more than one SSL option.  Only when connecting you can specify which one to use for the actual connection (if any).

 

So you are right that the user manager is not fully omplete for the GRANT syntax in this respect. But it wll not remove the need for an SSL tab in the connection manager if we add it. When connecting it is still necesssary to specif the SSL details.

 

Do we agree?

[peterlaursen]

This happens because the user you connect as when using SQLyog does not have privileges enough.  The same error would occur with any client installed on same machine as SQLyog. 

 

Command line will typically use the user ‘root’@’localhost and remote clients (like SQLyog) ‘root’@’%’ or  ‘root’@’some_specific_host’. They are different users in MySQL and may have different privileges. Most likely the remote user does not have the GRANT option. Please simply connect with SQLyog and execute “SHOW GRANTS;”.  If it read like “GRANT ALL ON *.* TO ‘root’@’%'” (and not “GRANT ALL ON *.* TO ‘root’@’%’ WITH GRANT OPTION“), the remote user cannot change privileges for any user. You will need to execute (as ‘root’@’localhost’ – what means that you wll need to do this in command lne or another cleint running on the server – “GRANT ALL ON *.* TO ‘root’@’%’ WITH GRANT OPTION;” in order to create a remote root user as powerfull as the localhost root user.

 

 

Besides, what you are asking here is not a SQLyog issue.  it isaout fndamental unerstand of privileges in MySQL . Refer MySQL documentatiion – in particular this page: http://dev.mysql.com/doc/refman/5.5/en/account-names.html 

[peterlaursen]

+ what type of graphics system do you have? If graphics share the RAM/memory with the system/CPU (such as Intel onboard graphics), it could be here that the ‘chain breaks’ somehow.

[peterlaursen]

I think we need to study this: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).aspx#physical_memory_limits_windows_xp

 

I notice here:

 

Version Limit on X86

 

Windows XP

4 GB

 

Windows XP Starter Edition

512 MB

 

 

 

 

What is the exact Win XP edition (I think there were 5 different + a “MediaCenter”  edition)? 

[peterlaursen]

I wish I knew how we could possible debug that. We will have to research.

 

If your hardware supports, install Win7 as well as SQLyog as 64 bit.

[Author]

Posts