[Shadow]

MySql provides the EXPLAIN statement for analyzing queries (only SELECT statements, though). It's quite impossible for a client to tell how MySql optimizes a query if no API is supplied… See the corresponding sections in the MySql manual (How MySql optimizes…).

[Shadow]

😀

You're welcomed!

[Shadow]

No worry, at first I have missed it, too.

[Shadow]

Hmmm, might be a good idea, if implemented as an option…

[Shadow]

Tools -> Preferences -> uncheck the 'Truncate column headers to max. data size' option.

[Shadow]

See the setting of lower_case_table_names variable. If it is set to 1, then the table names are stored in lowercase and table name comparison is case insensitive (from v4.0.2 on, this applies to the DB names as well).

[Shadow]

Do the table names contain characters that are considered illegal in MySql? (A dot /'.'/ for example)

[Shadow]

1). You mentioned an important difference between the two products, SQLyog runs on your machine, not on a remote server. Besides having the basic administrative functions (user, db, table management…), SQLyog has several additional features.

It lets you synchronize the structure or the data of two dbs, import data from ODBC sources, drop foreign keys, create a schema for a db in HTML. Moreover, you can even schedule the sync operations.

2). SQLyog uses the LOAD DATA INFILE command to import text files as well (which won't work in your case), but you may create an ODBC data source from that CSV file and use the ODBC import instead of text file import.

[Shadow]

If you take a look at MySql Administrator, then you'll notice that it is meant for administering MySql DBs only, while SQLyog is lot more then a simple admin tool. SQLyog offers additional synchronization and import tools, the possibility to issue SQL statements. I must aknowledge, however, that the administrative capabilities of MA exceed those of SQLyog, especially in the field of startup parameters and server logs.

Hopefully the long-awaited SQLyog Max will give a sufficient response to the challenge!

[Shadow]

That's not enough to find the reason of the error. Could you provide more info? Where is that target db, localhost or remote machine? User, port?

[Shadow]

That's a better idea! The best solution could be to allow the users to alter the default field mappings before the import and SQLyog would store the new default types. Agreed?

[Shadow]

The ODBC import wizard offers the transform option when you select the tables that are to be imported. The transform option enables you to change the field type to the desired type if the default does not fit your needs, so there is no bug whatsoever.

[Shadow]

Glad, that it works!

[Shadow]

Nay, the MySql won't take care of the privileges! Check out the documentation on MySql's website concerning an upgrade! You have to run a fix-privileges script!

[Shadow]

Have you checked the “Webyog releases SQLyog 3.64 RC1” topic in the news section? Do you have the corresponding version of SQLyog?

[Author]

Posts