[peterlaursen]

What is the program version you are using?

[peterlaursen]

What would you be willing to pay for such feature?

Currently the option is to install SQLyog Enterprise in Wine/Linux.

[peterlaursen]

First: I think you posted in the wrong category! This is a SQLyog report and not a MONyog report!

None of the things you report here have been reported before! The only known issue with SQLyog and Vista is that on some systems sometimes the program refuses to start. It can be necessary to reboot once more. This is not a problems with SQLyog alone!

No Vista specific issues with SQLyog are known once the program has started. I personally have been using SQLyog solely on Vista for 4 months now, and we test on Vista regularly.

What you report here looks very much like a the system itself is non-operational. I am not impressed by the 'finish' that MS gave Vista before releasing it (mostly I am very annoyed with all the localisations bugs), but a behavior like this is (after all) very unusual!

Please answer:

Have you been using SQLyog on other Windows without those problems?

Do you experience weird problems with other program as well?

Did you reboot the OS?

Did you try reinstalling SQLyog?

Did you try repair/reinstalling Vista?

Can you think of another program that you have installed that causes this weird behaviour?

On what hardware is this Vista installed ?

[peterlaursen]

The 'work-around SQL' (checked with version 5.32) is

Code:

show table status from `test` where engine is not NULL

[peterlaursen]

With hindsight I think I should have explained more in detail!

Traditionally the SQL used to get a list of tables is “SHOW TABLES”. However with MySQL 5 this statement retrieves both TABLES and VIEWS. So when we introduced support for MySQL 5 with SQLyog 5 we needed another query to populate the Object Browser with tables. What we did was (and that was as recommended by MySQL A:cool::

SELECT … FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE = 'BASE_TABLE'

This had two issues.

1) In the beginning of MySQL 5 queries to Information_Schema could be incredibly slow! This is (more or less) fixed by MySQL AB – but still querying Information_Schema can be considerably slower than “SHOW … ” statements.

2) We enocuntered quite frequently the same issue as you report here: that the SELECT FROM INFORMATION_SCHEMA.TABLES … -query returned an empty set even when tables were there that could be accessed with the privileges of the actual user.

We 'worked around' both by changing the query back to a SHOW statement (in version 5.1.something, I think). However, there seems to be an unwanted regression here. Version 6.05 still do

SELECT … FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE = 'BASE_TABLE'

(you can see in HISTORY tab)

I believe this is a mistake we made when we 'merged' the code for the version 6 tree! I also think that we can (and shall) correct this before releasing version 6.05 FINAL! I will ensure that we disucss this tomorrow morning.

But still: it is not a real bug in SQLyog. It is an issue with the server/OS configuration! Only you (or your Sysadmin) can fix this. And even if we solve it by returning to the SHOW statement, this should be corrected on the server, because sooner or later it will give other problems as well!

If you do not manage the server yourself you will need to report it to the support personnel at the ISP (or whatever).

You won't have to go into details with SQLyog. Just tell that the query:

Code:

select `TABLE_NAME` from `INFORMATION_SCHEMA`.`TABLES` where `TABLE_SCHEMA` = 'test' and `TABLE_TYPE` = 'BASE TABLE'

(substitute the database name with your own)

… returns an empty set when it should return a list of the tables that you have the privileges to access!

[peterlaursen]

It is true of course that copying (or restoring from a backup or sync'ing) a populated 'child' table would fail because of the foreign key CONSTRAINT if not the 'parent' table was populated in advance. That is why the SET FOREIGN_KEY_CHECKS command was invented.

Alternatively you would have to populate the tables in a certain order, and the server has no way to generate that order itself. It would involve a lot of application code to find out that order (and in the (rare) situation where references are circular it would simply not be possible at all).

I cannot explain what happened this time when you had the error. Looks like the server 'forgot' or 'ignored' the SET FOREIGN_KEY_CHECKS command.

And yes .. If you can reproduce it then please report details!

[peterlaursen]

PROGRAM VERSION PLEASE !!! Did you try latest available version? .. how often will we have to ask those questions ???

What does 'fails' mean? a SPECIFIC description please, EXACT error message ?!?!

The solution for such problems with Foreign Keys ALWAYS is to “SET FOREIGN_KEY_CHECKS = 0”. This should be done by the program. If it does not it is a bug! … So again: PROGRAM VERSION PLEASE !!! Did you try latest available version?

[peterlaursen]

we have had this a few times before. it is most often becuase the server was incorrectly updated from a previous version. Is it a 'shared server' ?

it is a privilege issue on the server basically. SQLyog queries Information_Shema to get information about tables. However if you upgrade SQLyog you will see tables too. We now use another query to retrieve the information – also because querying information_schema sometimes can be slow.

[peterlaursen]

Specifying charsets/collations different from upper-level (server or database) default with CREATE DATABASE and CREATE/ALTER TABLE is not yet supported from SQLyog GUI. We plan to add this in version 6.1 (first beta maybe by end of next week allready).

Untill then you will have to create (or alter) table using SQL like for instance:

Code:

CREATE TABLE mytable COLLATE

You can also (now already) define collations for individaul columns

Once the table is created you can ALTER TABLE from GUI and add more columns, indexes etc.

Also note that ALTER TABLE …. COLLATE .. does not change the charset/collation of existing columns.

… OK .. agreed. I little bit silly maybe that we untill now supported (non server-default) charset/collations definitions for COLUMNS and not for DATABASES and TABLES. But it not not because of this post that it is coming now .. we decided that more than a month ago!

[peterlaursen]

I am sorry! I think you are subscribing to the NEWS section? We are preparing an announcement and have a hidden post ready for that. I was not aware that the procedure that we follow would trigger such mails!

There is nothing wrong with the links! This Forums system uses the 'double slashes'! The issue is that the post is hidden! We will unhide very shortly!

[peterlaursen]

@Marco …

I would really like to know if your system is a Dual Core / Dual Processor too?

[peterlaursen]

1) @JimZ: please read this FAQ.

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

The 'escape mechanism' that we use in SQLyog GUI to distinguish between a KEYWORD and a LITERAL is `backticks`. “NULL” is the keyword NULL – “`NULL`” is the literal string 'NULL'.

2) accordingly we will release version 6.05 soon (probably tommorrow) where the string ” '' ” (two singlequotes) will be treated like a KEYWORD is this special context only: the DEFAULT column of CREATE/ALTER TABLE. To set default literally ” '' ” you enter ” `''` ” (two singlequotes surrounded with backticks).

[peterlaursen]

YES ..

With MySQL up to 4.1 a varchar can be 255 characters .. not 555 characters. I you need a variable longer than teh max. value for varchars you will have to use s TECT (or BLO:cool:.

This is a server issue and no client can change that!

[peterlaursen]

To create the column as TEXT statement would be like

ALTER TABLE `configuration` CHANGE `set_function` `set_function` TEXT CHARACTER SET latin1 COLLATE latin1_swedish_ci NULL DEFAULT NULL;

With very early 3.23 TEXT may not be supported – then you will have to use BLOB. it does not make much difference with such early server versions either!

but …. you cannot use 'COLLATE … ' if version is not 4.1 or higher!

To get the server version just execute “SELECT version();”

It isn't just a typo that you write '555' and not '255' ?? 🙄

Now did you consider using SQLyog GUI 'ALTER TABLE' (right click the table and select from context menu). What SQL is generated you can see in HISTORY tab.

[peterlaursen]

Actually this is a silly/a wrong error message! it should read 'use TEXT instead' (and not 'use BLOB instead').

The error message is a MySQL server error – not a SQLyog error. Only from version 5.0 MySQL supports varchars longer than 255 characters. With MySQL 5.0 it is 64 K byte (number of characters depends on the character set and the language as characters may occupy 1-3 bytes each depending on character set and language)

What is the MySQL server version? As you use a COLLATE statement I would guess it is 4.1.x!

The solution is to

1) upgrade MySQL to 5.x or 6.x

2) or use TEXT types for character data longer than 255 characters

[Author]

Posts