[peterlaursen]

First let me explain what I meant by 'simple filesharing'! By UNCHECKING it you will have more detailed options to define privileges to folders and files than if it is CHECKED. You or some program could then accidentially have changed something related to write privileges to part of the file system for this user.

Still you did not answer:

1) did you have an earlier version installed? Did you find the backup of sqlyog.ini and did you try to replace it?

2) did you try if problem is the same for another user?

I can tell that several thousand copies of version 6.06 has been downloaded. We have no similar reports and did not encounter this on any of the around 20 systems that we have ourselves.

There must be some special reason/issue! If you have this option please also try installing on another system.

[peterlaursen]

1) if you upgraded from a previous version there should be a backup file in the installation folder. You you replace the sqlyog.ini in 'AppData' folder what will happen? You will see old connection details, but can you add new ones

2) I also think there might be an issue with the user account. Could you try creating a new user, log on as this one and see if problems persist?

[peterlaursen]

We will try again to reproduce the fast data entry crash. Could you attache 1 or 2 dumps more (as

they may give a hint).

[peterlaursen]

please confirm that you mean sqlyog.ini , not mysql.ini!

[peterlaursen]

Also is 'simple file sharing' on or off on that system?

Did you use any program or 'tweak' modfiying permissions?

[peterlaursen]

First please try to find the sqlyog.ini file in users /application data/sqlyog folder and view it in an editor! No sections of the file like [connetcion …] ?

If for instance you enable/disable another option like 'word-wrap' doesn't that have effect? I think we should first find out if the file is created and updated!

[peterlaursen]

In SQlyog 6.06 sqlyog.ini is stored in user's 'application data' folder. Deleting the installation folder will not delete this file!

But this issue should not occur with 6.06 at all.

Once you find the (really used) sqlyog ini, can we have a copy of it? Create a ticket if it contains details you do not want to expose in public?

[peterlaursen]

Please tell the SQLyog version and the Windows version!

Starting from version 6.06 sqlog.ini is saved in user's 'application data' folder (and where that is depends on whether the Windows is Vista or an earlier windows version).

Are you telling that the dropdown of the connections manager does not display a list of saved connections?

[peterlaursen]

@chris …

I do not recall details about the clipboard problem. Are you referring to another Forums post?

Please explain or give a link …

[peterlaursen]

I understand you like you are talking about the BLOB viewer?

1) What is your setting in tools..preferences.. “enable wordwrap … ” . If checked it works OK for me.

2) “a search facility in that dialog box…” That dialogue box is (still) the BLOB viewer I think? Yes and I would even go further and say that plugins for the BLOB viewer similar to the image plugin (a simple HTML-editor, a HEX-editor, even a simple media player etc) would be nice! This has been on 'wishlist' for some time, but other issues have been considered more urgent!

[peterlaursen]

let me explain:

When we originally introduced reconnection it was only implemented in the 'main' GUI. For structure sync, dublicate/copy operations and batch jobs it was added later. Structure sync was added in 5.22 as the last. Structure sync was the programmatically most difficult one to solve.

It was temporarily disabled again in internal builds 'on the way to 6.0' and by mistake it was simply forgotten. Only when we had 2 complaints almost simultaneously (the one by Chris and one in the ticket system) it was sorted out what had happened and fixed in 6.06.

Versions 6.0 to 6.05 will not reconnect automatically in structure sync no matter the connection method, This bug is NOT SSH-related!

It looks now like some issue with SSH and reconnection (not in Structure Sync but everywhere!) has occured. We asked Marjolein to compare different versions becuase we judged that she had a setup fit for such test, just as we have a similar test running at office since Friday. If this is an issue introduced in 6.0 or in late 5.x versions I hope Marjolein's information as well as similar information from our own test will reveal.

When Chris had no saticfactying answer, it is simply because we could not reproduce it. Of course SQLyog will stop trying to reconnect if it has tried with no succes (but actually I am not quite sure if it tries 1 or 2 times – I remember we discussed but I am not sure about the conclusion).

The culprit is if there is consistently reproducable difference between 6.x and various 5.x versions. Marjolein seems to have clear indications of this and this we take seriously!

[peterlaursen]

Actually …

Currently we show tables and basic information about the tables only in OBJECTS for a database.

I think we should also list SPs, Functions, Views etc. with similar basic information about those – at least this information

* DEFINER

* SQL_SECURITY

And there could be a 'additional information' like default charset/collation as you proposed (I verified that there is nothing more added to SHOW CREATE DATABASE in MySQL 6.0)

Just like I think the OBJECTS for tables should display triggers defined as 'triggered by' operations on that table with information about each like 'BEFORE UPDATE', 'AFTER INSERT' etc.

Basically the information in OBJECTS as of now does not reflect changes in MySQL after verson 4.0! A little strange only that we never considered this ourselves and had no similar requests before!

[peterlaursen]

I think the best solution is that we should populate the OBJECTS tab for the connection itself!

We could display the connections manager information and the variables that are most important for SQLyog operation. We should also briefly explain how the affect SQLyog operations

I do not think 'uptime' is very relevant in the SQLyog context (we have MONyog for monitoring). Those are most relevant I think:

* server version

* server default charset and collation

* max_allowed_packet value

* storage engines available (and which is default)

* local infile (ON/OFF) setting

* lowercase_table_name value (1/2/3) setting

* global sql_mode

* event_scheduler status

and maybe

* # of active threads, idle / not idle count

[peterlaursen]

Thanks for your considerations.

We will check the inconsistencies you point to here.

For 3 years or so focus has been on features, the GUI is almost untouched.

Maybe you are right that we should 'balance that focus' soon.

[peterlaursen]

1) there is the menu tools .. show

2) there is an icon in the icon bar, see image

[Author]

Posts