[osolo]

Thank you.  This is exactly what I was looking for.

[osolo]

navyashree.r wrote on Jan 12 2009, 12:41 AM:

Hi Osolo,

This request already there in our list but priority is not fixed. Hope you enjoying our product and Thank you for your interest.

http://code.google.com/p/sqlyog/issues/detail?id=432

Regards,

Navya

Navya/Peter,

I'm wondering why this trivial bug exists since 2007 and something a single person asks for is fixed in a day?

Thanks!

[osolo]

peterlaursen wrote on Dec 9 2008, 12:04 PM:

well .. not need to file! The ones you have customized display with a warning symbol. You should back up those!

Reasons I think this is a bug:

1. Installer gives no warning that its going to wipe everything (though I do see now in the main interface that it does say that, but its very easy to miss, as I have)

2. There is no way to “bulk” save all changes. I have a lot of changes so it's a pain to save then restore. It's only going to get worse when you allow customizations based on servers.

Now image there is a “bulk” backup. That's definitely useful if I have multiple MONyog installations and I want to transfer settings between them. But for upgrades, I would be doing a backup, install, restore which leads me to ask – Why not just give me the option during install to keep my customizations?

[osolo]

Thanks Peter. I upgraded to 2.9 and issued a flush and now it's OK.

“Delta” doesn't apply here because the “max connections” will be the same all the time. That was my problem to begin with…

I noticed that when I upgraded it wiped all my customizations to the monitors. I consider that a bug. Where can I file it?

Thanks,

Oz

[osolo]

Rohit wrote on Nov 30 2008, 05:02 AM:

Unfortunately, there is no way to specify the server specific configurations in the current versions of MONyog.

However, we are thinking of exposing the server registration details in the MONyog Object Model (MOM) so that you can script server specific advisors.

We will discuss this with the MONyog development team and get back to you.

That would be great! I'm finding more and more that global settings just don't work for me because each database instance is unique.

I think your scripting engine is impressive, but I'm hoping you'll find a way to make something as fundamental as this integrated into a UI so that I don't have to constantly mess around with scripts.

[osolo]

Mahesh wrote on Jul 25 2008, 01:12 AM:

HI,

We will give you a test build over our ticket system,

Please create a ticket from here,

http://www.webyog.com/support/

Thanks for your co-operation.

I opened Ticket #4520.

[osolo]

peterlaursen wrote on Jul 6 2008, 03:24 PM:

@Adarsh ..

you were with Webyog so long that you (should) know that statements (also DDL statements) executed from the editor are simply sent to the server, are not parsed and have no immediate effect on the GUI. They have effect on the server of course – provided that that the statement is valid. You have to REFRESH the relevant Object Browser node (in this case the connection node) to make the change visible in the GUI. Or just drop from the Object Browser context menu instead!

This applies not only to 'drop database' statement but *any* create/drop/alter statement. Just like you will have to REFRESH the DATA GRID so see the effect of DML statements (insert, delete, update) in the GUI

I do not exclude the possibility that some 'parsing layer' will be added at some later point to add 'synenergy' between GUI functionalities and Command Line/Editor functionalities (basically the alias support is some kind of parsing added recently). But it is not priority.

Peter –

I would add to the list the need to refresh after a “Restore from SQL Dump”. I'd say its desirable to refresh the tree *always* after this command is used since there is a high chance that there will be changes.

[osolo]

peterlaursen wrote on Jul 24 2008, 10:53 AM:

sorry .. I did not see your 'nested reply' above!

That's OK. Let me know if you need more information.

For the record – this has happened on two different computers, and it happens all the time. If you have some special debug build, I'd be happy to run that for you.

[osolo]

Manoj wrote on Jul 24 2008, 03:15 AM:

Hi osolo,

Can you give the result of “Select version()” from both the servers?

Have a look a few posts back:

osolo wrote:

My “Server A” is: mysql Ver 14.12 Distrib 5.0.45, for Win32 (ia32)

My “Server B” is: mysql Ver 14.12 Distrib 5.0.45, for pc-linux-gnu (i686) using readline 5.0

Select version() shows less information:

Server A: 5.0.45-community-nt

Server B: 5.0.45-community-log

[osolo]

Direct connection in both cases.

[osolo]

Mahesh wrote on Jul 24 2008, 01:01 AM:

Please tell the exact version of program for which you got the crash? then only the dump will be helpful to us.

7.01 Enterprise.

[osolo]

peterlaursen wrote on Jul 23 2008, 01:36 PM:

The error that 'mysql server has gone away' may or may not be an issue with SQLyog!

Is it *consistently reproducable* that this specific sequence of operations raise that error?

Could you tell the server versions and attach the my.ini/my.cnf file for the server(s).

We will analyze this tomorrow. Program should not crash anyway! Hopefully the DUMP will give usable information.

The problem is with SQLyog since the mysql server definitely did not go away and if I start SQLyog it can reconnect without any issue. It is 100% reproducible, but sometimes I need to change the sequence slightly to get the error.

My “Server A” is: mysql Ver 14.12 Distrib 5.0.45, for Win32 (ia32)

My “Server B” is: mysql Ver 14.12 Distrib 5.0.45, for pc-linux-gnu (i686) using readline 5.0

Config files attached.

[osolo]

navyashree.r wrote on Jul 21 2008, 02:18 AM:

Hi,

Can you please attach the screenshot of the error message and also can you please brief out about the point why “confused”?

Thanks in advance.

Regards,

Navya

Sorry for the late response. For some reason I didn't get an email when you posted…

Here is what I am doing to reproduce:

– On connection A create a table called foo_dev

– On connection B create a table called foo

– In foo_def, add a view

– Start sync tool

– Syncrhonize

– Press compare again

I attached an image of the error that shows up.

Also, while I was playing around trying to reproduce, I got a crash. I'm attaching the dump file as well.

[Author]

Posts