[slimso]

peterlaursen wrote on May 24 2007, 03:24 PM:

thanks for your feedback.

however we will concentrate on releasing 6.0 FINAL before considering the display.

personally i always thought that HISTORY should display execution time for each individual statement, but what MESSAGES and STATUS line should display is open to me.

Ok, no problem, it's not really an urgent matter.

Anyway, keep on doing a good job with 6.0!

You might remove the “Bug:” in the topic name, to avoid confusion.

Thank you for your time!

[slimso]

peterlaursen wrote on May 22 2007, 11:00 PM:

why not ….. ??

well we actually asked users what they wanted (I think) about 9 monts ago!

Now what would YOU think would be teh most unambigious and useful way to display the information?

I'm not claiming to be pertinent, but I think that the time displayed in the MESSAGES tab should be the approximate execution time.

The MESSAGES tab displays how many rows were affected or returned. It is a server response to the query, so it would be appropriate that “0 ms taken” would also refer to a server response (the “execution time”), not to a “data transfer time” that is particularly misleading if the client is on a remote host.

Here's an example of why I've posted this topic:

Code:

UPDATE users_14_copy SET email = CONCAT(email, '9999');
SELECT CONCAT(email, '9999') FROM users_14_copy;

after execution the MESSAGES tab displays:

Code:

(75647 row(s)affected)
(0 ms taken)

(75647 row(s)returned)
(10 ms taken)

and the HISTORY displays:

Code:

/*[14:34:21][4156 ms]*/ UPDATE users_14_copy SET email = CONCAT(email, '9999')
/*[14:34:21][ 10 ms]*/ SELECT CONCAT(email, '9999') FROM users_14_copy

I think I would have liked to see that the UPDATE query actually took 4 seconds instead of seeing how long it took for the response to get from the server to my remote client…

[slimso]

peterlaursen wrote on May 22 2007, 05:39 PM:

It is not a bug really.

Please refer to:

http://webyog.com/faq/8_147_en.html

HISTORY displayss the closest we can come to 'server execution time'. MESSAGES as close as we can come to 'time for transmission of data'.  On localhost it will have to be a very big result if it shall not be 0 (zero).

If you experience behaviour different from what is explained here, then please detail, because then it may be a bug!

Sorry I didn't search further before posting.

It's a shame mysql doesn't supply this information itself, like it does with LAST_INSERT_ID() or ROW_COUNT()…

But why not display the 'server execution time' in the MESSAGES tab and 'server execution time' + 'time for transmission of data' in the HISTORY tab?

It's kinda useless to keep on seeing '(0 ms taken)' where one would expect the execution time.

[slimso]

OK, it works!

Didn't fully tested it, but i'm confident the problem is solved.

Topic closed i guess.

Thank you.

[slimso]

Well, i've done better than that. I've installed version 5.24 and made some screenshots too.

Here's the ALTER TABLE statement after opening the “Alter table” dialog and changing the field name from “priceOld” to “priceOlds”:

Code:

alter table `deliverit`.`prods` change `priceOld` `priceOlds` float (10,2) DEFAULT '0.00' NOT NULL

Here's the original CREATE TABLE statement (as shown in screen1.gif and screen2.gif):

Table Create Table

---

---

prods CREATE TABLE `prods` (

`ID` smallint(5) unsigned NOT NULL auto_increment,

`catID` smallint(5) unsigned NOT NULL default '0',

`brandID` smallint(5) unsigned NOT NULL default '0',

`typeID` smallint(5) unsigned NOT NULL default '0',

`photoID` smallint(5) unsigned NOT NULL default '0',

`name` varchar(500) default NULL,

`price` float(10,2) unsigned NOT NULL default '0.00',

`priceOld` float(10,2) unsigned NOT NULL default '0.00',

`stock` tinyint(3) unsigned NOT NULL default '0',

`link` varchar(200) default NULL,

PRIMARY KEY (`ID`)

) ENGINE=MyISAM AUTO_INCREMENT=1369 DEFAULT CHARSET=latin1

This is not a SQL related problem, it's just and UI bug: the “Alter table” dialog does not read the “float(10,2) unsigned” corectly.

When opening the “Alter table” dialog, the “Unsigned” flag is not checked even though the data type of the field is FLOAT UNSIGNED.

If I choose to “Alter” the table, the program behaves properly and alters the datatype to float signed because the “Unsigned” flag was indeed not checked (not by me though).

[slimso]

peterlaursen wrote on Jan 29 2007, 02:03 PM:

fixed in the development tree.  Beta 2 with the fix will be released tonight or tomorrow.

Thanks for the quick action guys, i've checked beta 2 and the new stable release 5.23 and it does work, except …

Don't mean to nag you, but it still doesn't recognize the “unsigned” flag.

So when you open the “Alter table” dialog, the “Unsigned” checkbox is unchecked.

This causes a problem if you indeed alter the field, because it is modified back to “signed” without notice.

Again, the problem only appears for FLOAT or DOUBLE fields.

Thank you.

[slimso]

I've tested it and the feature works in MySQL 5.0.27-community-nt via phpMyAdmin on the same table (MyISAM).

Also SQLyog recognizes it as “float unsigned” but can't reassign the same datatype again.

So i guess it's just a tiny bug…

[Author]

Posts