[peterlaursen]

As I told, all this is not reproducible for us.  It is specific for your environment. We also have no other such reports. Please do not assume that what you observe is a general problem. Feel free to check on another system, if you have another, for instance.

 

Now, the information used by SQLyog to identilfy keywords etc. are read from an SQLite database (‘keywords.db’). This file is stored in the installation folder (as it is not written to) We have seen before that some over-aggressive AV-tool and similar restrict the communication to and from SQLite databases (and we read *a lot* there – for every keystroke actually).  What ‘securtiy tools’ do you use?

[peterlaursen]

“it had just deleted all of my saved sessions”.  No, I believe it had not. ‘something else’ or ‘somebody else’ did. One way this could happen is if an old backup is accidentially restored.  This could happen from the NTFS file system ‘shadow copy’ for instance.

 

If you are using WIn7 and have ‘system restore’ enabled on that drive you could check for previous versions from the file context menu .. properties .. previous versions. 

[peterlaursen]

It is not the SQLyog installer that touched the .ini file.  We dont write to that folder at all from the installer.

[peterlaursen]

I forgot this:

 

In 11.4 preferences .. “Font & Editor Settings” -tab, please try to click ‘Restore TAB defaults’ -button.

[peterlaursen]

Either you don’t understand what we are telling or we don’t understand you. For isntance you claim that with 8.12 “syntax is coloured”.  It also is with 11.4. Settings for same are available in ‘preferences’.. Please see attached image. Here comments are defined to display with *blue’.

 

[attachment=1944:colors.jpg]

 

 

 

If you are interested we can sit togehter in a ‘shared session’ and you can explain us what you mean and vice versa.  if you are interested please drop a mail to [email protected] and we will reply with login details to such session

 

 

 

 

Besides a ‘fixed SSH port’ is not a *bonus*.  it is actually extremely dangerous in some cases! Consider the situation where the sqlyog.exe crashes while using SSH tunnel.  The plink.exe process will continue to run.  If you next try to establish a SSH connection to another server using same local port you will connect to another server than what you’d expect (and consider if you next execute a DELETE or DROP statement). Also another SSH-enabled program (Putty, Filezilla, whatever) may already be using the local port you specify.  Disasters may result.  That is why we changed it so that SQLyog will ‘pick’ an unused high-numbered port and reserve it for its own use.  Should SQLyog close/crash leaving plink running, next time SQLyog opens a SSH connection, a new plink instance will be started on another port.

[peterlaursen]

I have replied in the other Forums post.  besides I think you created a ticket as well and we have replied there.  The problem is *not* reproducible on our environment.

 

Since  reverting to an old version did not resolve the problem, it looks like an issue specific for your envirnment.  I have asked you to reboot your system. Did you?

[peterlaursen]

The FAQ is our policy. In principle we only distribute and support the lastest stable version. This is our decision and our business model. There are basically 2 reason for this:

* if user wants to use an older version, we want to know *why*

* we release so frequently (up to 2-3 times per month) and it is impossible to support them all. And if a fix is required it will go into a coming version.  Old versions are *as is*.  If we change as much as a COMMA in an old version it will not be the same version anymore.

 

 

That said: we provide older version in most cases to users requesting so.  But we want to know what the problem with latest version is.

 

 

(and the post here is OK to keep alive, I think.  Why not?)

[peterlaursen]

There is a checkbox ‘Limit rows’.  This is a per-table setting.  When you are trying to view that table is this checkbox checked or not? You may accidentially have unchecked it.

 

If it is unchecked, please try to STOP before memory gets exhausted. Now check the checkbox and REFRESH.

[peterlaursen]

I found a trick!  You may try to set the SESSION variable for one variable that has different ranges on 32 and 64 bit systems.

 

One such is “bulk_insert_buffer_size”

refer https://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_bulk_insert_buffer_size.

 

Now if you

 

SET SESSION bulk_insert_buffer_size = 429496726;

SHOW VARIABLES LIKE ‘bulk_insert_buffer_size’;

.. what is returned?  If the server is 32 bit it will be ’rounded down’ to ‘429496725’, I think (or first statement may result in an error or a warning).

(don’t forget to SET the variable back to a reasonable value).

[peterlaursen]

And in the bug report I added:

 

 

I tried on a local Windows 64 bit 5.6.15 server. Here version_compile_os is “Win64”.

However a Linux 5.6.12 server (official MySQL/Oracle server binary) that I have access to (added here: the one running here on webyog.com actually) only returns “Linux” for this variable.

 

[peterlaursen]

Ok – DonQuichote was on the track already. But “SELECT VERSION();” does not expose this (I tried with both Windows and Linux servers).

[peterlaursen]

Good question.  I have asked the same here http://bugs.mysql.com/bug.php?id=72019.

 

(and in principle, this isn’t strictly a question related to netiher SQLyog nor MONyog – so a more appropriate place to ask would be the MySQL Forums for instance.  You are welcome to ask here, though)

[peterlaursen]

“To avoid this you must explicitly enter “=” in criteria field”.

 

This is per design.  How should we/SQLyog know what operator user wants to use (“=”, “<>“, LIKE or whatever)?

[peterlaursen]

“Also the queries inside the procedure are are totally missing from query analyzer data”.  You may use the Query Analyzer with (slow or general) log files, processlist-sniifer or proxy-sniffer.  Which one did you use? 

 

Anyway .. what you executed was a CALL statement, right? Does the server expose (in any of the above options) what is executed *inside the Stored Procedure*?  MONyog will infromation from log contents, from SHOW FULL PROCESSLIST or from the statement sent by the client through the proxy.  it cannot know anything internal for the server, the server does not expose. 

 

 

We will look into the query time and other issues. But please also tell both the MySQL server version and the MONyog version.

[peterlaursen]

Then I am afraid we don’t understand!

 

Please attach

1) a screenshot of each of the 2 tabs in tools .. preferences: “Power Tools” and “Fonts and Editor Settings”

2) a screnshot from the editor with comments what should be different (use the WIndows “Paint” program for instance to add comments, paint arrows etc. pointing to the problem)

[Author]

Posts