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

Feature Request

forums forums SQLyog SQLyog: Bugs / Feature Requests Feature Request

  • This topic is empty.
Viewing 5 reply threads
  • Author
    Posts
    • #11769
      Shiro
      Member

      Hello,

      I wish to have the view last / latest record button between next page record,

      I feel this feature is very useful, I used to it with phpmyadmin and Navicat, not sure why SQLyog still haven't implement this feature yet.

      I know I can be done, but with 2 click, click the ID twice can saw the effect as well in front page, but how about i am in second page, so…

      I don't think it is a very hard feature, just help user do thing more fast, thx~

    • #30073
      peterlaursen
      Participant

      Can you please explain me what 'the last record' in a database table is?

      In my understanding there is no order defined for data as they are stored. If you SELECT * from a table (with no ORDER BY) you will not always get data in the same order from the server because

      1) it depends on indexes/keys

      2) after dumping and importing a table rows may be returned in another order than before.

      .. so it can actually be very misleading to claim that some row is the 'last row'. Some users would expect a PK-sort (if a PK exists) – others a timestamp sort (if a timestamp column exists).

      But you are probably right that with an auto_increment INTEGER PK on the table the server will always return rows in same order. But with no auto_increment INTEGER PK, I think such 'feature' is very misleading.

    • #30074
      Shiro
      Member
      'peterlaursen' wrote on '01:

      Can you please explain me what 'the last record' in a database table is?

      In my understanding there is no order defined for data as they are stored. If you SELECT * from a table (with no ORDER BY) you will not always get data in the same order from the server because

      1) it depends on indexes/keys

      2) after dumping and importing a table rows may be returned in another order than before.

      .. so it can actually be very misleading to claim that some row is the 'last row'. Some users would expect a PK-sort (if a PK exists) – others a timestamp sort (if a timestamp column exists).

      But you are probably right that with an auto_increment INTEGER PK on the table the server will always return rows in same order. But with no auto_increment INTEGER PK, I think such 'feature' is very misleading.

      ok, you got the point, when there is no auto_increment as PK. For the last record /first record feature didn't have the weight function usage.

      But as you know most of the time, ppl create table will create an ID as auto_increment as PK.

      If you think this feature is misleading, maybe create as an option, by default it is disable, when ppl like me want to use it got the feature to enable. If this feature really useless or misleading why phpmyadmin and other mysql GUI still keep it? it sure got it purpose. I suggest created as an option.

    • #30075
      Shiro
      Member
      'Shiro' wrote on '02:

      ok, you got the point, when there is no auto_increment as PK. For the last record /first record feature didn't have the weight function usage.

      But as you know most of the time, ppl create table will create an ID as auto_increment as PK.

      If you think this feature is misleading, maybe create as an option, by default it is disable, when ppl like me want to use it got the feature to enable. If this feature really useless or misleading why phpmyadmin and other mysql GUI still keep it? it sure got it purpose. I suggest created as an option.

      so what is the outcome? Will this feature consider on next build?

    • #30076
      peterlaursen
      Participant

      hmmm .. we have < and > buttons in data tab.  We could add << and >> buttons. That should then return the first/last rows (as defined by current LIMIT setting).  Something like that you imagine?

      One problem is that for >> we will need first to execute a SELECT COUNT (*) – what can take very long time (= several minutes) to return result with large InnoDB tables (SHOW TABLE STATUS cannot be used as it is not exact – it only returns an 'estimate' with InnoD:cool: and an exact 'rowcount' with InnoDB is sometimes horribly slow. This is actually the reason why we did not introduce <<  and >>  when we introduced < and >.

    • #30077
      nithin
      Member

      Hello,

      The request is already added in our issue tracker. We will consider this enhancement after 8.2 GA release.

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

      Thanks

      Nithin

Viewing 5 reply threads
  • You must be logged in to reply to this topic.