[peterlaursen]

Forth and Back 😮

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

QUOTE

In order not to break legacy applications, support for TYPE = engine_name has been restored, but now generates a warning.

Important: This option has been deprecated since MySQL 4.0. Beginning with MySQL 5.2, TYPE = engine_name will no longer be available and will produce a syntax error. You should not use TYPE in any new applications, and you should immediately begin conversion of existing applications to use the ENGINE = engine_name syntax instead. (Bug #17501)

FAQ write-up: http://www.webyog.com/faq/32_80_en.html

[peterlaursen]

Now that other issues that confused (a SQLyog 5.1 BETA bug, an issue with sql_mode) are sorted out:

It is VERY CERTAIN that I can write special characters ON THE SAME (Apache + MySQL) server and PHP 4.3.x. With latest versions (5.1.2 and 4.4.2) I can't. I can't find anything in PHP changelogs that relates to this!

added: This has now been verified on more MySQL versions

[peterlaursen]

The problem with tunnelling to MySQL version 5 server that have not

Code:

@@sql_mode = ''

as default setting for sql_mode

can be solved by inserting into tunnelling file after

Code:

   /* Function will execute setnames in the server as it does in SQLyog client */
   SetName ( $mysql );

Code:

   /* each connect must set sql_mode */    
   $sqlmode = mysql_query(“set sql_mode = ''”, $mysql);

another fix is to replace mysql_connect() with mysql_pconnect(). _pconnect means 'persistent connection'. But not all ISP's/web hostings allow for it.

Probably Ritesh will post a more professional solution soon. It could be necessary to test for MySQL version with mysql_get_server_info() (if the statement raises error on MySQL < 5.0. But this fix and the fix that Ritesh allready implemented solves it all with all MySQL and PHP versions, I believe!

[peterlaursen]

Status:

Things here are now fully sorted out and explained. Ritesh found one issue, and I another. One is a bug in 5.1 beta, another involved setting sql_mode over a tunnelled connection. Pretty complicated as things were 'intertwined' quite a lot.

One fix is implemented in 5.1 code tree, the other probably later today!

[peterlaursen]

One more then:

http://bugs.mysql.com/bug.php?id=17817

[peterlaursen]

I could not help myself:

http://bugs.mysql.com/bug.php?id=17809&thanks=4

[peterlaursen]

FAQ write-up:

http://www.webyog.com/faq/32_80_en.html

[peterlaursen]

Now that I have played a little around with EVENTS on MySQL 5.1.7, I have some considerations on HOW this could be implemented in SQLyog.

Just like SP's VIEWs etc. an EVENT is defined with a database, so there should be an EVENTS folder in Object Browser for each database. For at start simple templates to 'create event' and 'alter event' would be fine. A 'drop event' too.

There should also be a GUI-option to enable/disable EVENTS that simply executes

SET GLOBAL event_scheduler = ON/OFF;

There is one problem/consideration only. That is that EVENTS are user-specific. peter@localhost and ritesh@remotehost may both create a `myevent`with identical names. Shall SQLyog only display user's own EVENTS or all (they are all availble with a SELECT …FROM INFORMATION_SCHEMA). I go in for an setting to let user decide. Of course peter cannot ALTER ritesh's EVENTs, so they should be 'greyed out'. They must also display as

*myevent(peter@localhost)

*myevent(ritesh@remotehost)

to avoid confusion when EVENTS with identical names exist.

[peterlaursen]

😀

Actually there is a C-connector available for Postgresql, so it it not impossible! But it is a lot of work! And quite a new world for everyone at Webyog

[peterlaursen]

Problem with upload of attachment confirmed. Though I have FTP-access to the server I am not permitted to CHMOD this folder and its content!

You will have to wait for Ritesh to show up in the morning. Fixing this issue takes ROOT-acces to the RedHat OS from a remote SHH-shell, I believe! It is crazy. We had some similar issues with the attachments folder of the FAQ-system. An LAMP config issue with the Red Hat systems. I stick to SuSE myself!

Could you explain the buffer-overrun issue in VERBOSE mode? 😉

How to reproduce?

It has not been reported before, I myself haven't either had this.

Did you install 'over' existing version or in a new folder?

[peterlaursen]

Also note from the changelogs:

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

QUOTE

Incompatible change: TYPE = engine_name is no longer accepted as a synonym for the ENGINE = engine_name table option. (TYPE has been deprecated since MySQL 4.0.)

This is implemented in SQLyog ver. 5.1 (beta) like this. It queries the MySQL version and uses KEYWORDS 'type' or 'engine' as appropriate. SQLyog versions before 5.1 alwasy use KEYWORD 'type'.

thus you will have to use SQLyog 5.1 to CREATE TABLE, ALTER TABLE, REORDER COLUMNS etc. with MySQL 5.1.7+

[peterlaursen]

Now 5.1.7 is now out on FTP mirrors.

There is no installer-version for Windows this time. There also was quite a lot of bugs reported with the installer script for 5.1.6. Even 'Monty' himself reported a couple of bugs with it. I also seems that most MySQL developers had forgotten that there was such thing as Windows – they completely forgot to provide a Windows version of the mysql_upgrade program (that replaces the mysql_fix_privileges.sql script). On Windows you will have to run mysqlcheck with the new on_update option and next the mysql_fix_privileges.sql, if you want to use it with an existing /datadir. I recommend that you dump and reimport your databases.

There is now (again) max-versions of the servers in the package. Something is confused here! Looks like an internal communications problem in MySQL AB. Deep silence in the threads at bugs.mysql.com where users have asked for an explanation!

However the issues with previous versions with partitions (crash on querying INFORMATION_SCHEMA, VARIOUS deadlocks) and events-related privlege issues seems fixed. Events really work now!

And it is not an ALPHA anymore. It has been promoted to BETA. Seems fair enough for the server alone, but not for install- and maintenaince scripts and programs! They are EARLY ALPHA in my opinion! And further: User administration with 'MySQL Administrator' is completely broken (at least on my system). “user root@localhost may be deleted” it claims when trying to edit privileges. However I can log on as ROOT! I can create other users but cannot edit their privileges either.

But it works OK with SQLyog – even user administration does. Unfortunately it is not complete. But that gives us an opportunity to learn GRANT syntax … <_<

[peterlaursen]

I just tested with SQLyog 5.1 BETA 1 and it seems to be fixed here already. Simply clicking 'refresh' displays the newly imported database (`utest` in this case – the latest in alphabetical view). No need for any tricks like jarsyl's with 5.1! 🙂

[peterlaursen]

Two ways

1) Also uncheck 'Lock all tables for read'.

2) Grant user LOCK_TABLES privilege. I think that this is a reather new privilege that you cannot manage from SQLyog. Use commandline client or MySQL Administrator as long as SQLyog does not support it!

Both methods have been tested here on MySQL 5.1.6 as a user having only SELECT (and LOCK_TABLES for 2nd way) only.

@ritesh: I think that 'Lock all tables for read' is CHECKED as DEFAULT. I think it should not be as long as SQLyog does not support the privilege from User Management.

[peterlaursen]

Just let me add that SQLyog makes extensive use of MySQL SHOW statement, which I don't believe Postgresql or any other RDMS support. So it would be an almost complete rewrite of everything.

[Author]

Posts