Unsupported Screen Size: The viewport size is too small for the theme to render properly.

Forum Replies Created

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • istoeckel
    Member

    Thanks dudes a lot 😎 It worked!

     

    You’re a lifesaver

    in reply to: #34557
    istoeckel
    Member

    @abushek and @marriott79

    YES! That’s exactly what i have been trying to explain to the Developers / SQLyog Team. I proposed a SOLUTION to solve the single-connection limitations and still be user friendly enough so that it’s not annoying 😉

    After using MS SQL Studio, Workbench, Toad and countless others i found this limitation very frustrating.

    Hopefully someone from the Webyog Team will listen 😎

    in reply to: #34553
    istoeckel
    Member

    As far as I understood it is a limitation as to how SQLyog is implemented and thought of from the beginning, for one Tab (not connection) to not use more then 1 single connection to the DB. Since it’s the first SQL client i’ve seen with this restriction … i’ve learned to live with it, but when it’ll come to new licences, I will definitely suggest Navicat or any other another MySQL Client (without this limitation)

    in reply to: #34551
    istoeckel
    Member

    This has been discussed several times before and we won’t change anything in this respect

    May i ask why? You are the only SQL client i have encountered with this limitation. I have tried to adapt but it’s still a big nuisance 🙁

    In order for you to better understand i will give is an example of my current working environment and how some very simple limitations (in my opinion as an ex-programmer) could be easily addressed:

     [attachment=1976:Untitled.png]

    In the above screenshot i have 3 database connections to 3 different servers i use on a daily basis. Inside each server/connection i usually have multiple tabs for some of the SQL’s i need to run or am analyzing for performance issues.

    While running one lengthier query, say a couple of minutes, I would like to be able TO AT LEAST COPY some SQL content from ANOTHER TAB (ones with Query title) in order to create a new connection (as requested by your limitations) and be able to execute / work on something else while the first executes. I DO NOT want to execute 2 or more queries on the same connection, i just want to be able to COPY things from EXISTING Query tabs in order to BE ABLE TO WORK in a new connection AS PER YOUR SOFTWARE’S LIMITATION. I cannot in many situations anticipate how long a query will last, but i don’t want to be stuck and be FORCED to wait for it’s execution.

    WHY can i not switch to another TAB, i do NOT want to execute something from there, i do NOT want to expand tables or ANY OTHER OPERATION which would need to make a call to the DB, I JUST WANT to be able to access MY WORK from OTHER TABS  <_<  ! When the executed query is finished you can easily focus back on the finished query, anyways the UI is being refreshed at that point, or just leave the existing tab focused, whatever is easier for you…

     

    I understand your reluctance because from the start you’ve worked like this and accepted it as the way to go. But as a previous user of TOAD and MS SQL Management Studio i find this limitation not just weird but also unjustified. Please, try to put yourself in the shoes of other DBA’s / Developers and hopefully you could understand and this in turn could get you the appreciation of current and even future customers 🙂

     

    Thanks in advance

    in reply to: #34549
    istoeckel
    Member

    I know it works in a new connection, but i do not want that. I think it’s the first SQL editor that I encounter which freezes your editor while your query is executing and the new connection workaround is not a preferred solution for me. If you’re working only with simple/fast queries it’s ok, but if you’re a power user i don’t think its reasonable.

     

    Usually when I’m working on something i like to keep them grouped withing the same connection and keep variants or parallel related work in different Tabs. One of the advantages is that you can name and save these query tabs independently while the query is executing. When moving to a new connection all the previous work done is gone and i have to start from scratch, as mentioned, not even copying works and it’s way to limited and not productive in any kind of way.

     

    I understand the decision performance-wise, but the edit-ability of a Query Tab should not depend on a single open connections. There are workarounds, for example: yes, disable auto-complete (or use a local cache, the way MS SQL does it)l disable the ability to expand Tables / DB in the left hand pane (displaying a similar warning message as in the Query Tab when it’s busy), it’s just a text window with some highlighting (which is great by the way).

     

    Thanks for your fast answer and i hope you take this into consideration.

    in reply to: #34547
    istoeckel
    Member

    I would like add this as a feature request since MySQL Workbench can do this.

     

    I do not mean concurrently executing more queries, but the ability to change the content of the current Tab, open new Tabs (and be able to edit them), just not execute a different query until the running query is finished. You could only just freeze the current Tab but you can’t even copy data from the existing query! I find this a big nuisance and time being wasted.

     

    Unfortunately it wasn’t my decision but i would have chosen Navicat over SQLYog just because of this.

Viewing 6 posts - 1 through 6 (of 6 total)