[cap10morgan]

Supratik wrote on Jul 4 2008, 03:45 AM:

I am giving you a not released version of MONyog-2.5 RC n2 x86_64 RPM and TAR.

You may clear the cookie and install this version in your system, this will log the error.

Please send us the MONyog.Log and change your private data in MONyog.Log before sending the file.

You can download the not released version from the following URL.

RPM

TAR.GZ

Regards

Supratik

Where should the log file be created? I can't find it in /usr/local/MONyog or /var/log.

[cap10morgan]

Supratik wrote on Jul 3 2008, 03:58 PM:

We are trying to reproduce this issue at our end, meanwhile can you please tell us whether your browser is configured to accept cookies.

Regards

Supratik

Yes, both browsers I tested with accept cookies.

[cap10morgan]

Supratik wrote on Jul 3 2008, 02:57 AM:

Can you please give us some more detailed information.

1) What is the browser you are using ?

I've tried it with both Safari 3 and Firefox 3 (Mac OS X). Same behavior in both.

Quote:

2) Does it happens the same with other browsers also ?

Yes.

Quote:

3) What is 'myhost' in the URL “http://myhost:5555/” ?

alinsky.pirg.org, which is my MySQL server, and the host MONyog is running on. I'm connected to it over a VPN and can access it directly on all ports via that connection. No other service is having connection issues. Apache is not running on this system, just MySQL and MONyog.

Quote:

Regards

Supratik

[cap10morgan]

peterlaursen wrote on Apr 10 2008, 04:53 PM:

ok .. let us discuss if the 'restore ..' option should be removed from the database context menu.

But SQLyog does not 'read' (parse) the content of an external file at all. We cannot display a warning. Also there may be more USE statments in a file (not one generated by SLQyog) so it is not enough to read the beginning of the file.

OK. A potentially better alternative is making the “Include USE statement” unchecked by default in the backup to sql dump option so that the behavior is more in line with expectations. Then put a general warning on the restore dialog that, depending on the statements in the dump, the current database isn't a restriction on where this data is headed. Because currently that dialog implies that it is.

[cap10morgan]

peterlaursen wrote on Apr 10 2008, 04:07 PM:

This is a misunderstanding on your side, I believe!

When you import a dump it executes WHAT STATEMENTS ARE IN THE DUMP. If the DUMP contains the statement

.. it will of course do so! If the dump does not contain a USE statement it will import to the latest database selected in GUI.

Are you sure that the option to “include 'use' statement” was not checked when exporting and that the dump contained the USE statement?

Yeah, that's probably what happened. But…

I'm not sure whether that box was checked or not; it's whatever the default was. But it doesn't matter. This is still a bug. If a GUI gives you a right-click option on a database that says “backup to sql dump” and then a right-click option (which implies, I want to do something to this object) on another database that says “restore from sql dump” and then that dialog makes a point of proclaiming the current database (in bold, no less), then it should not, under any circumstances, silently restore that dump to a different database. If this means it should detect the USE statement in the dump and issue a big, fat warning or else ignore it for the purpose of this restore, then so be it.

As a user, I shouldn't have to know the ins-and-outs of USE statements and what they're telling the MySQL server to do in order to grasp that the GUI is misleading me. Especially when the dump in question could have been made ages ago, or by a different program. SQLyog should detect when a dump is going to override what it's presenting to the user (within reason, of course, and I could would consider looking for a USE statement w/in reason) and either issue a warning or silently do the right thing. At the very least, it should always warn that restoring from a dump may not use the current database, and offer to let you examine the dump first.

[cap10morgan]

Has this been fixed as of v. 5.16? If not, when is it planned to be fixed?

Are there any other outstanding issues with using SQLyog Enterprise on a MySQL NDB cluster? We're possibly moving to one in the next three months.

Thanks!

[Author]

Posts