[marriott79]

 

 

I agree, If user just want to access content of other query tab and absolutely nothing else(user doesn’t want to navigate in his sever using Object browser, doesn’t want to execute query, and don’t want to go over table data tab, info tab..etc ) then SQLyog should allow you to do this. SQLyog then will restrict navigation to all the other tabs except query tabs.

 

@Abhishek Kumar Pandey

 

Sorry, perhaps I wasn’t clear. What you wrote above is exactly what I’m requesting — to be able to access the current connection’s query tabs and be able to keep typing in them. It makes perfect sense that we wouldn’t be able to browse objects or perform other database tasks in the same connection. This is reasonable. Like you said, I would [not] want SQLyog to generate more connections behind the scenes.

[marriott79]

I see, so it has to do with the design of the code. That’s a shame because it sabotages/limits an otherwise good product. I think I’ll have another look at Navicat. Thanks

[marriott79]

I’d also like to vote for this “feature” to be implemented. I recently purchased the Ultimate edition after years of frustration with MySQL Workbench. So far I like SQLyog; however, I respectfully think you’re making a big mistake locking down the tabs in a connection while a query is running. Essentially, you’re forcing users to fit your work-flow, which won’t work for many people.

 

I’m expected to run many ad hoc queries on a daily basis to monitor operations and diagnose problems. Usually, I’ll have several tabs open, each with five or more queries in them. And I’ll have something like this set up for three different databases (i.e., three different SSH connections open at once).

 

At any moment, my boss might ask me for several pieces of information, which require multiple queries. I have no control over the connection speed or the indexes on the tables, so a query might take 5-10 minutes to complete. I’m okay with waiting for one query to finish before I run the next one, but it’s a complete waste of time if I can’t work on (edit) other queries in that connection while I’m waiting. The last thing I want to do is open more connections as a work-around.

 

As someone pointed out above, this “feature” is supported by virtually every SQL client out there, including MySQL Workbench. Is there some technical aspect that makes this difficult to do in SQLyog? Again, I think you’ve got a pretty good program here, but I’m not sure if I’m going to stay with SQLyog if it’s going to hinder productivity.

 

“We have tabs in 2 levels: connection tabs (on top) and for every connection tab an option for multiple query tabs . I cannot understand why it makes a big difference.”

 

 

It makes a difference because there’s very little cost associated with adding a new tab to an existing connection (in most programs anyway). However, opening multiple connections has a ton of overhead. Essentially, you’re asking us to open multiple connections (a resource-intensive and wasteful work-around) in order to have the ability to continue editing SQL for the same database when a large query is running. If we changed our work-flow to fit your preferred method, we’d have multiple (tons) of connections open to the same database instead of multiple tabs open within a single connection. I can’t understand how you wouldn’t see this as a problem. Work-arounds like this shouldn’t be necessary when dealing with advanced SQL clients. If we (the customers) didn’t have advanced needs (such as cranking out a ton of SQL on the fly), we’d all be using free programs like phpMyAdmin.

 

I used to work as a product manager, and we lost our biggest account because the development team refused to implement a simple feature that the customer had requested several times. Try as I might, I just couldn’t get through to our developers that a small fix would make the customer happy because it would save them [a lot] of time and hassle each day. But our developers insisted customers should do things [our] way. “If it’s not broken, why should we fix it?” was the basic thinking.

 

Not every customer will reach out to tell you what you’re doing wrong. Most will just silently go with the competition. I do think this is a big limitation to an otherwise good product, so I hope you’ll reconsider implementing this feature.

 

Two other “nice-to-haves” would be the option to disable the “Info” tab from automatically opening with each new connection, since it can cause the entire program to freeze while it gathers information I’m not interested in. And also it would be nice if you could run a query from the visual query builder without having to copy the SQL to a new tab first. But these are minor annoyances compared to the issue above.

[Author]

Posts