[ronjeremy_69]

peterlaursen wrote on Dec 19 2006, 11:02 AM:

A Forum is for use at a Forum!  You can ask your questions here.  That is the idea!

Peter, the fact you actually bothered to take time to reply to this post is testament to your excellent dedication to the forums — but unfortunately I think this is a spammer who is fishing for valid email addresses. These spammers seem to becoming more frequent, you might want to look into captchas or something to prevent spambots from registering/posting.

[ronjeremy_69]

peterlaursen wrote on Dec 14 2006, 12:46 AM:

So let us hear what people want (and the argumentation not at least)!

It would be most useful to have the STATUS bar number reflect the query execution time on the server and be as close to what you would get with the mysql command-line as possible. As such, the STATUS bar number should mirror what you would see in the History tab. This is how i cast my vote, and i believe rrkramer would as well!

[ronjeremy_69]

peterlaursen wrote on Dec 13 2006, 11:56 PM:

This is simply not possible and never was. The server does not send this information. Also the 'mysql' command line client gets this information from the client machine.

I also am not aware of any intentional change here, but let us discuss.

To test, I use the command-line mysql client to query a 200,000 row table with “SQL_NO_CACHE” and “limit 1” on a non-indexed column, and the client reported the query completed in 0.41 seconds. Then on a windows machine i ran the same query on SQLyog v5.22 Beta 2 and the STATUS bar reported 0ms. then i uninstalled and installed 5.12 and the STATUS bar reported 431ms, which is pretty much exactly what the command line reported (and how it should be).

[ronjeremy_69]

Im not quite sure the reason this was changed?

One of the main reasons I use SqlYog is to prototype and find optimial queries that will be part of an application on the server itself. From a developer's standpoint, really I could care less knowing the amount of time it takes to actually transfer data from the mysql server to my windows PC and display it. A number showing me milleseconds elapsed depending on the kind of network connection I have and how fast my client PC can display data in SqlYog is irrelavent.

What is most relavent is how fast my queries will be executing on the server itself. In the past, it was great to be able to press F5 on a few variants of the same query and see the milliseconds elapsed in the STATUS bar to decide which query was optimal. It is inconvenient to have to flip back and forth to the History tab between each F5. I cant think of any reason that knowing the time elapsed sending data over the network could possibly be more important than knowing the time the query itself takes to execute, especially when 90% of the time on a LAN it will be 0ms (unless the resultset is large)?

I propose either changing it back to the way it used to be, or having it so there are both indicators in the STATUS bar. Theres plenty of room down there:)

[ronjeremy_69]

I noticed this a few days ago also — although i didnt have enough time to investigate too deeply my observations were that the statusbar number showed 0ms for most short queries, something other than 0ms for longer queries, but in no case did it ever match up with the query time shown in the “history” tab. I remember it working properly in pervious versions also (Im currently using 5.22 Beta)

[ronjeremy_69]

Alternatively, SqlYog might finally implement the simple feature i have been requesting for years (“Show Table Data in text”).

In “show results in text” mode, Sqlyog can display a select * on a one-million row table with 15 columns in around 20 seconds. The only thing that stinks is i want to just single-click on the tables to see everything (in text), but there is no such option.

Try doing that with grid mode — task manager time!

[ronjeremy_69]

Ritesh wrote on May 29 2006, 12:10 PM:

Last and not the least, I have just increased the priority of this feature in our to-do list!

One year (and six months) later, still waiting patiently.

Single-Click a table, table data appears as text (instead of in grid). That's all im looking for. One small option. Please try to make it happen!

[ronjeremy_69]

Ritesh wrote on May 25 2006, 05:35 AM:

Hmmmm….

Sounds interesting. Prolly, we will implement this in v5.3.

Could I convince you to include it in v5.14 for $100?

[ronjeremy_69]

The Mask wrote on May 24 2006, 01:04 PM:

Hi

There is a problem with SQLyog whereby functions with a routine_body can not be created.

Example:

CREATE FUNCTION hello (s CHAR(20))

RETURNS CHAR(50)

RETURN CONCAT('Hello, ',s,'!')

The above works fine but if you enclose any statements in a routine body, an error occurs.

CREATE FUNCTION hello (s CHAR(20))

RETURNS CHAR(50)

BEGIN

RETURN CONCAT('Hello, ',s,'!')

END;

…gives: Error Code : 1064

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'RETURN CONCAT('Hello, ',s,'!')

END' at line 4

(0 ms taken)

Any ideas please?

This is not an issue with SQLYog! I tried your case in mysql's standard command line program and got the exact same result.

[ronjeremy_69]

Ritesh wrote on May 24 2006, 03:14 AM:

It is not very difficult to implement but then we will not be able to provide features like filtering(planned in one of the future versions), sorting etc. as there will be no column headers to work with.

sorting in text mode would be nice, but i can certainly do without it. I wouldn't expect that feature to be available in text mode anyway. I would imagine it would behave just like the results-pane: in grid mode the column headers, checkboxes, “copy to clipboard”, etc buttons are available, but by turning on “Show Results in Text” they disappear.

[ronjeremy_69]

peterlaursen wrote on May 23 2006, 06:06 PM:

@ron

I think we all understand that you and probably others as well request that feature! Since it is not implemented it most likely is not so easy. Might involve quite a lot of restructuring of the data structures and code 'behind' the DATA tab.

What about a keyboard shortcut (CTRL + * ??) that executes 'SELECT * FROM current_table (and maybe using a LIMIT too)' and opens it in a RESULT tab. That could probably be implemented easily. Combined with another pending request that it should be possible to 'freeze' a RESULT tab (or make it 'sticky' if you like), I think you get what you need?

Actually CTRL + * could use LIMIT and CTRL + SHIFT + * could use NO LIMIT.

Comment?

good ideas, but there are a couple important points being missed. the first is one-click functionality — a keyboard shortcut solution would require two steps: one to first click on the table, and another to execute hotkey). The secont point is that browsing several table's data as text should not “dirty-up” the query editor with a bunch of “SELECT *” statements. it needs to happen in such a way that the query editor is unafected.

[ronjeremy_69]

CalEvans wrote on May 23 2006, 05:30 PM:

I know I've got to be missing somehting because CTRL+L workes in everything but the “Table Data” pane.

Select * from mytable;

F5 and then CTRL+L and I can copy and paste away.

As I said, I know I'm missing somthing here.

(Ritesh, it would be nice if Table Data honored the CTRL+L switch and I agree with Ron that it would be nice if SQLYOG remembered this setting across reboots.)

=C=

CTRL+L only works on queries you are executing in the Query Editor. The feature I am requesting would require absolutely nothing to be in the Query Editor in order to see the table data. Currently, SQLYog can already do the one-click-show-tabledata by clicking on a table –> table data shows in “Table Data” in a grid. The option I am requesting would behave almost the exact same way, except “Table Data” would show the data as text instead of in grid.

[ronjeremy_69]

peterlaursen wrote on Apr 27 2006, 02:37 PM:

I don't Ritesh will need that.

This is an issue on the client side – no a server issue.

I just think that things have been a liitle too 'tense' the last week for Ritesh fully to consider this – due to the MySQL Users Conference and the crashing bug.

Sounds good, just wanted to offer. The fact Ritesh has kept up with forum replies while at the conference is impressive in itself!

[ronjeremy_69]

Ritesh wrote on Apr 26 2006, 01:23 PM:

We have not changed any code regarding reconnection. It must be something else. Right now I am in MySQL UC 2006 in Santa Clara and will take a look into it after reaching India on 2nd.

I have anyway asked my developers back in India to reproduce the case but they are unable to.

Is it possible to provide temporary access to your server so that we can check it out?

I am also experiencing this issue after upgrading to 5.11 final (and now 5.12 BETA). Ritesh, if you still cant reproduce I can grant temporary server access.

[ronjeremy_69]

It's easy to add with SQLite, but the “COALESCE” function seems to be missing.

[Author]

Posts