[Shlomo Priymak]

'Khushboo' wrote on '24:

Hi Shlomo,

This feature request is already listed in our issue tracker,

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

Right now priority is not set. We will discuss regarding this feature and prioritize accordingly.

Thank You.

Regards,

Khushboo

Thank you!

I'll try to look at the tracker before I post a request next time.

[Shlomo Priymak]

+1 on this one.

I usually need to modify the query for this, and it would be more natural to select those cells directly.

[Shlomo Priymak]

'Khushboo' wrote on '12:

Hi Shlomo,

Thank you for your suggestion.

We have added your request in our issue tracker:

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

You can expect this feature in SQLyog 8.5 Beta2, which will release probably on the coming Monday.

Regards,

Khushboo

Excellent! Thank you! 🙂

[Shlomo Priymak]

Sabyasachi Ruj wrote on Jun 30 2008, 05:00 AM:

1. Can the same (which is being used to run MONyog) Ubuntu user access the log file?

2. Does the user account have super user privileges which is being used to run MONyog?

3. Can you try starting MONyog in 'root' user?

4. What is the size of the log file that MONyog can not access?

1. Yes

2. MONyog is not run using super user privileges.

3. Will do, but I do not intend to do so regularly.

4. About 2-3 GBs. I usually look at it using tail.

What could I check futher to assist you? It seems it should just work. Maybe it is somehow related to the fact it tries to access the wrong path, such as given in the error – “'/mnt/vol/slow.log'”? Or are those back-slashes only a display issue?

Shlomo

[Shlomo Priymak]

Manoj wrote on Jun 28 2008, 03:24 PM:

Hi,

Are you running MONyog in a Windows OS? if yes, make sure the service is running with admin privilages, by default it is “Local system”.

Negative. This is an Ubuntu Server 7.10 64bit.

[Shlomo Priymak]

peterlaursen wrote on Jun 24 2008, 08:24 PM:

ok …

1)

now first .. I think Supratik meant if you were using SSH connection to MySQL. But I understand that you don't. You are testing this Monyog build on a Linux machine and you are connecting to a MySQL server running on the same machine. Please confirm!

2)

Please attach screenshots of the 4 registration/configuration settings for this server (hide what *text* details you think appropriate)

* MySQL server details

* SSH server details

* Log analyzer settings

* Sniffer options (for completeness only!)

1) The MySQL server is running on another machine and MONyog on another, but the log file is accessible from both the machines as an NFS mount (so it's a “local path” configuration). Both machines have access to the file, under the same path. I am using an SSH connection for the system properties, naturally.

2) Attached. Hope I didn't remove useful information.

[Shlomo Priymak]

Supratik wrote on Jun 24 2008, 06:54 PM:

Hi,

Can you please give us a few details of your configurations .

1) Have you tested the log file path ? did you get any “Log file path invalid” message ?

2) Are you using direct connection or via SFTP ?

Regards

Supratik

1) Yes, the path is correct, and is validated when using the validation in the server configuration page

2) I am most certainly using direct connection, don't have SFTP configured at all.

[Shlomo Priymak]

peterlaursen wrote on Jun 24 2008, 06:39 PM:

1) plase checked that you have checked the 'local file' option/radiobutton. I could think you you have SFTP option checked and entering path to a local file?

2) no clue from here rihgt now!

2.5 ships with new SFTP code, so probably *somehow related*. Was 2.0x was able to find the .pid file wihtout problems (for system counters) ?

1) I checked that specifically in the configuration… And it also gets the properties correctly from the database, just it's my guess it's trying to use sftp to access it… don't know for sure.

[Shlomo Priymak]

Stig wrote on Apr 30 2008, 01:05 PM:

Correct. The 'user' would not be able to change their password, it would be configured by the 'admin'.

It would allow the value the product provides to be consumed by a larger consumer base.

I second that request – it's a real need for us as well.

—

Shlomo

[Shlomo Priymak]

peterlaursen wrote on Apr 24 2008, 11:32 AM:

If you are connecting to localhost then MESSAGES and HISTORY may be the same with very fast queries as there is no significant connection 'overhead'. First, second and third TIMESTAMP could be the same millisecond. Does this explain?

I tried executing a 'not-trivial' query to localhost (changing a table from MyIsam to InnoD:cool::

Code:

alter table mytable engine = innodb

now

HISTORY displays

/*[13:21:27][ 374 ms]*/ alter table mytable engine = innodb ;”

and MESSAGES:

(515 row(s)affected)

(0 ms taken)

So here the MySQL server requiered almost 0.4 second to write data to the InnoDB tablespace, delete the MyIsam files and update whatever system tables and logs needed to be updated. HISTORY tells. MESSAGES tell that communication overhead between server and client is neglible with this connection.

Interesting. So in a case where communication between client and server is slow, “messages” should tell me how big the lag is.

I ran a heavy query on a remote server, to which I surely have more than 200ms lag.

History shows this:

/*[18:40:13][52978 ms]*/ alter table log engine = archive;

While messages says:

(37767 row(s)affected)

(0 ms taken)

Just like in your example. But in my case, communication is surely very slow. I get a ping lag of ~250ms to the remote site. Or is lag somehow deducted from this calculation?

peterlaursen wrote on Apr 24 2008, 11:32 AM:

As regards the Formatting request:

We have not had a team assembly since your first post but you can tell if you think it would be sufficient to do this formatting/calculation in the Status Bar?

Sure, it's good enough in the status bar… Although a configuration option that can do this for history/messages as well could be cool too. Anything above 60 seconds is very hard to grasp right away with just the milliseconds number, regardless of the location in the program.

IMHO, I would re-consider the UI logic here, so that it would be more straight-forward for new users.

Have 2 different measures, like now, only display them differently.

History should stay as it is – this is the same time the mysql command line client displays, basically.

Messages should display the same time like History, with an addition like “n ms overhead”:

(37767 row(s)affected)

(0 ms taken, 5 ms network overhead)

Due to the fact it's plain text, it's easy to be fooled into thinking it's the same time as the mysql command line client. This is at least what I've thought so far – and I thought it was a bug since I see it at 0ms.

Status should display not the last query time, but the summary of the “history” times for all of the queries. I personally run batches a lot, and it is really useful to know how long they ran. Right now I need to sum the results from the History window…

Don't mean to be nitpicking, but it's just how it makes sense to me personally 🙂

Regards,

Shlomo

[Shlomo Priymak]

I see, so the measurements I was looking for are in the History tab… I understand it better, but I think I'm still missing something…

When executing single statements, the times in the messages and the times in the history are always the same, at least in the queries I've tried running.

What is the difference between the 2nd and the 3rd timestamp collections? Both of them are collected after the server reports a successful execution. The 2nd after the server returns a flag, and the 3rd after “execution of few lines of code”.

And what do you think about my second comment?

Quote:

On another note, I would be really great if instead (or in addition) to the “X ms” in the status bar, it would say something like “X minutes, Y seconds, Z ms”. For longer queries, the “ms” is useless, and I find myself using calc and counting digits.

[Shlomo Priymak]

I see.

Well, as longs as it's on the list 🙂

Thanks…

[Shlomo Priymak]

peterlaursen wrote on Mar 24 2008, 01:11 PM:

We found the issue for the structure sync issue.

http://dev.mysql.com/doc/refman/5.1/en/news-5-1-23.html says

“It was not possible for client applications to distinguish between auto-set and auto-updated TIMESTAMP column values.

To rectify this problem, a new ON_UPDATE_NOW_FLAG flag is set by Field_timestamp constructors whenever a column should be set to NOW on UPDATE, and the get_schema_column_record() function now reports whether a timestamp column is set to NOW on UPDATE. In addition, such columns now display on update CURRENT_TIMESTAMP in the Extra column in the output from SHOW COLUMNS. (Bug#30081)”

and http://bugs.mysql.com/bug.php?id=30081 says (Jim Winstead is a MySQL developer)

“It is not possible to tell, from the contents of the MYSQL_FIELD structure, whether a

TIMESTAMP field will be set to CURRENT_TIMESTAMP on UPDATE. Connector/ODBC needs to be

able to determine this in order to properly return results for the SQLSpecialColumns()

ODBC function.”

This change affects only 5.1.23. Not 5.1.22 and no 4.x, 5.0 or 6.x builds either (yet).

We will have to take that change into consideration with structure sync (we execute SHOW FULL FIELDS from struct sync to get information about the tables involved).

Interesting. Sometimes I'm really surprised how much things MySQL changes between such minor versions…

Glad to have found that one first, I guess 🙂

[Shlomo Priymak]

peterlaursen wrote on Mar 23 2008, 05:41 PM:

1)

What do you mean “Yes, I see that this is indeed not possible, and never will be. Can't say I'm very pleased with that.” It IS possible. Please read the FAQ! Just check the 'Not Null' checkbox and that is it! The server will create a 'default CURRENT_TIMESTAMP on update 'CURRENT TIMESTAMP”.

The first NOT NULL timestamp in a table is automatically CURRENT_TIMESTAMP on update 'CURRENT TIMESTAMP” unless some other default is declared. This is implemeted in the server like that for compability with versions before 4.1

2)

……..

3)

Please provide a test case of two complete database structure-only DUMPS.

I was referring to this part of the FAQ which says it's impossible:

Quote:

With the CREATE TABLE and ALTER TABLE GUIs, however, you cannot create TIMESTAMP definitions like

e) NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP

f) (NOT) NULL DEFAULT 'yyyy-mm-dd hh:mm:ss' ON UPDATE CURRENT_TIMESTAMP

Those constructions – that are both very rare – can be handled from the editor. Users who want to use those will undoubtedly also understand. We do not find it justified to add yet another column to the CREATE TABLE and ALTER TABLE GUI's that can be used only for a single datatype and can only have one single value when it is not really required.

But I understand what you meant now. So much errata makes things hard to track…

3. Sure, no problem. No need to shout 🙂 Dumps attached.

[attachment=862:5.1.22.txt]

[attachment=863:5.1.23.txt]

[Shlomo Priymak]

peterlaursen wrote on Mar 23 2008, 04:56 PM:

1) To define TIMESTAMP properties with SQLyog read

http://webyog.com/faq/content/8/159/en/how…ith-sqlyog.html

2) The 'coupled' checkboxes in structure sync GUI is a known issue (also reported some times before here). This will get our attention after 6.5 final. We will try to provide more 'fine grained' control of what can be sync'ed and not display checkboxes for object that cannot be synced independently

3) I cannot reproduce reported problem with Structure Sync (6.5 beta1) and TIMESTAMPs. See attached.

Both dabases has a single table like

CREATE TABLE `tstest` (

`id` int(11) NOT NULL default '0',

`ts` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,

`tx` varchar(30) NOT NULL default 'a',

`bl` varchar(30) NOT NULL default 'b'

) ENGINE=MyISAM DEFAULT CHARSET=utf8

Can you provide a test case: a structure dump for two databases to be compared?

[attachment=860:not_here.jpg]

1. Yes, I see that this is indeed not possible, and never will be. Can't say I'm very pleased with that.

2. One of those low priority yet annoying bugs I guess…

3. The table structure is completely the same (and i'm also using 6.5 beta). I have 5 of those tables, each one says the diff is on this column. The dump will just be the same. I have no idea why this could be. Does SQLyog read the information_schema tables? Maybe there is some difference there between 5.1.23 and 5.1.22?

I've taken your table, and created it on those two databases.

The one on the left is 5.1.23 and the one on the right is 5.1.22.

[attachment=861:sqlyog.jpg]

[Author]

Posts