[Rohit]

'Stacy wrote on '25:

I recall there being some prior discussion about SQLYOG's copy functionality being limited to entire row's and single cells. As you know, there is currently no ability to copy an entire column, or a set of selected cells within a column or row. (note: there is a work around to select adjacent column cells in a single row through Text Result mode).

Ideally, SQLYog would have this “Excel-like” ability to select various cells, rows, and cell-ranges that could then be copied. I did a quick comparison of this functionality between some popular query browsers used by people in my office. All tools allow you to copy a single cell, in addition to the following:

– SQLYog: Select/Copy entire row(s)

– MySQL Query Browser: Select/Copy entire row(s)

– Navicat: Select/Copy entire row(s) or column(s)

– Toad: Select/Copy any combination of selected cell

In comparison, Toad appears to have the greatest functionality providing the most “excel-like” copy functionality. While the cost/benefit of such functionality is debatable (I personally believe it to be extremely valuable), it would be great if SQLYog could be enhanced.

Perhaps the compromise would be to provide functionality similar to Navicat, which allows you to select/copy an entire row, but also an entire column. I wouldn't imagine that would be too complicated, compared to allowing the select/copy of any combination of selected cells.

Thank you for consideration.

Thanks for the nice suggestions.

Yes, Excel-like copy functionality will be definitely great.

We will discuss this internally and update this thread.

[Rohit]

We have plans to improve auto-complete drastically. For example: Parenthesis highlighting, etc.

An unbiased opinion about Toad:

While Toad for Oracle is a fantastic product, we find Toad for MySQL extremely sluggish & buggy for serious use. I would encourage you to try Toad/MySQL for some time and share your feedback here. We are always looking forward to new ideas & suggestions for our products.

[Rohit]

'DAE51D' wrote on '07:

Well, first of all, if speed is an issue, then make it an option/preference. I'd rather trade a few microseconds of speed for this convenience. Basically it's just a “DESCRIBE TABLE” on each table to get the number of columns. Seems pretty simple and cheap to me. Especially on a development database which is usually local or a VM or on a high-speed LAN.

Another acceptable solution is to populate the (#) part once a table's [+] has been expanded. As soon as I expand the “Tables” [+] then you know I have x tables, so have your code go back and populate the top “Tables (x)” title element — surely you can do this trivially. Same logic for any table I expand. Once I expand it, then you have a free count of how many columns.

Not only would it add the feature, but it also gives a free “clue” of which tables I've expanded already and which ones I'm probably using. As I expand and collapse the tree nodes, it's easier to jump and expand tables I've already opened since they'd be all the ones with a (x) next to their names. I'd say like 80% or more of your DB work is within like 3 or 4 tables, not your entire database. Easy to scan with the eye, especially if you were to color code it maybe in a shade of gray or the blue like the icon next to the name.

You could be really nice and maybe add a Right+CLICK menu item to “expand all” and “collapse all” — and this would accomplish the original feature requested if you implemented it as described here, because then by that one simple action, I get a tally of all the tables.

I think this solution proposed solves all problems.

Thanks for the suggestions. Some of them are great feature requests. We will add it to our wish-list. Our plate is full for the next 8 weeks.

[Rohit]

I think this is outside the scope of SQLyog. You can easily use a product like http://www.truecrypt.org/ and encrypt the folder containing sqlyog.ini.

[Rohit]

I didn't get your question/suggestion. Could you please elaborate?

SQLyog does not do any password mgmt itself. It completely depends on MySQL credentials.

[Rohit]

We had auto-expand everything in the 1st version of SQLyog (in 2002).

Then we changed it to expand on demand. Some users reported 1000x increase in speed!

[Rohit]

Although it looks good in theory, I would request you to test it out!

Set up the sync, delete the tables, restore it from the backup and make sure it's all good.

[Rohit]

'mawheatley' wrote on '30:

Hi – I had SQLYog 8.4 and it was set to check for updates automatically. I knew 8.5, and subsequently 8.5.2 were out, but it did not recognize this. I would also manually click “Check for updates” and it said “You are running the latest version.” I manually downloaded and installed 8.5.2 this morning, but thought you should be aware of this.

We increment the new version info in our servers only after one week of “bug-free” public release. This way if there is a bug, we can fix it before it gets distributed to millions of installations.

[Rohit]

It should be safe but not recommended.

If the operation fails for some reason, you wouldn't know the error messages, etc.

There are a couple of recommendations:

1) You can continue working on SQLyog by making a new connection.

2) You can minimize SQLyog and work on other apps

This way you know whether the operation completed successfully or not. I think that is important.

Does that answer your question?

[Rohit]

'intel352' wrote on '17:

Articles on MySQL are pushing InfiniDB (Community Edition) a bit, as a very speedy column-oriented solution.

Apparently InfiniDB is built on top of a customized MySQL platform?

Considering that, would SQLYog natively support InfiniDB?

http://www.infinidb.org/

I think InfiniDB should just work out of the box as are using standard MySQL Client.

[Rohit]

Even if the log file is large, MONyog should never crash.

Let Sayan comment here.

[Rohit]

Thanks for your patience!

From the dump, we can make out that MONyog crashed while parsing the Slow Query Log.

Can you try parsing your Slow Query Logs once again and confirm?

If a particular Slow Query Log is the culprit, please create a ticket at http://www.webyog.com/support and attach the Log File.

Once reproduced, we guarantee a fix within 72 hours.

[Rohit]

This is very strange. We don't have a similar report elsewhere

Can you try the same import with an old copy of SQLyog? From you description it looks like the problem has cropped up recently.

Anything else you can do to help us reproduce the problem? Can you attach some sample cases by creating a private ticket at http://www.webyog.com/support

In the meantime, we will try to reproduce your problem in a similar environment.

Can you tell me the following info?

1) Size of the SQL dump

2) Structure of the target tables

3) Target MySQL version

4) Innodb or MyISAM tables (Insert on Innodb is sometimes slower than MyISAM)

If we can reproduce the problem, we guarantee a fix within 72 hours.

[Rohit]

That is a good suggestion and we will discuss this internally. Will update this thread within a week.

[Rohit]

MONyog is extremely lightweight so collecting data from a lot of servers has never been a problem. The extra resources required for an additional server is minimal.

We have large customers who run multiple instances on MONyog using virtualization and are successfully monitoring appx. 200 MySQL servers per instance of MONyog. Of course, this number depends on your hardware and collection interval.

This does not mean that there are any known limitations with MONyog when the number of servers being monitored is more than 200. There might be some installations higher than that, but we have never communicated with them. Our unlimited licence is very flexible and we generally don't know the real number of MySQL servers being monitored by a particular customer.

Having said that, we love working closely with customers having large deployments.

Please contact us at http://www.webyog.com/support mentioning your requirements and we can give you an unrestricted trial so that you can find out MONyog's scalability yourself before buying licenses. We will also provide all the support you need to try MONyog in your environment. We are very passionate about making MONyog work with thousands of MySQL servers and the core MONyog development team will work with you to ensure that MONyog meets your expectations.

Does that sound reasonable?

[Author]

Posts