[Mitch]

This is still happening.

[Mitch]

It still causes me trouble also.

 

There is no fix yet. They have added it to the github issue tracker for possible future development.

[Mitch]

Thanks for that information. Both of those workarounds are valid. My problem with those is that I have to choose a file name for saving and then remember what that filename was later. This would not be a problem on a small scale, but I do it many times a day, and those times start to add up.

 

I guess I’m asking for a change in the way SQLyog operates in this situation. For me the current situation creates a somewhat inconsistent user experience, because some of my sessions are saved automatically (the ones open when I close the app) and others are not (those that I close separately).

 

Here are my ideas on ways to implement this. Given what I’ve seen of the application, I would guess that none of these are a lot of work.

1. Automatically save each session that is manually closed, similar to how they are saved when the app is closed. Do this in addition to whatever action the user chooses on the “Do you want to save the changes?” dialog? Restore this session when that connection is reestablished. 
2. Add a “Save session in automatic location” to the File menu, that would save the session in the spot that is automatically restored when a connection is opened
3. Add a tool bar button for #2
4. Add a right click option to the connection tab for #2
5. Add a “Save session in automatic location” to the “Do you want to save changes” dialog that pops up when a connection is manually closed.

[Mitch]

Is it possible to restore the saved connections in parallel? That would significantly decrease the startup time, and would do a lot to alleviate this timeout issue.

[Mitch]

Are the stored connections restored sequentially, or in parallel?

[Mitch]

Any feedback on this? It is really causing me grief.

[Mitch]

@Jay – Until the developers take an interest in this feature and put it in place, the Visual Data Compare works nicely. 

[Mitch]

I am now on Ubuntu 16.04 (XFCE) 64 bit and Wine 1.6.2

SQLyog 12.2.6

 

This is happening a few times a day. It seems more frequent than before.

Is there any hope or help for this issue?

I have a dump file if that would be of any use. (SQLyog_Dump_009.dmp)

[Mitch]

Here is the reply from the support team about this issue:

 

In a Self-signed SSL Certificate, the Common Name value used for the server and client certificates/keys must each differ from the Common Name value used for the CA certificate.

 

You get this error as the Common Name value for the server and client certificates/keys and the CA certificate are the same.

This was not enforced in the client library we used before 12.2.6. However if names don’t differ you wll be vulnerable to ‘man in the middle’ -attacks. So this won’t be reverted.

 

 

 

[Mitch]

Can you provide a link to download the previous version?

[Mitch]

Thank you for that information.

 

I still believe that my request has merit and hope that it will be considered.

[Mitch]

I am still having problems with this in Ubuntu 16.04, though the symptoms have changed somewhat.

 

When I install SQLyog, it places an icon on the desktop. I can drag that icon to the Ubuntu Launcher and it does launch the program, but the active icon in the launcher for the running program is not the same as the one used to launch it – i.e. after starting the program, there are 2 icons, the one that I used to start it with and the one that represents the running program.

 

Any ideas on how to fix this?

[Mitch]

Thank you for that information.

 

I think the original request is still valid.  Since that error message does not affect the execution of the query, but only the EXPLAIN, SQLyog should treat it as a warning message, perhaps in the EXPLAIN output window, rather than a pop-up error message.

[Mitch]

It is working for me now also.

[Mitch]

I have noticed this also.

[Author]

Posts