[Ritesh]

Same issue as all other “strict mode” issues!

[Ritesh]

This again has an issue.

I think MySQL versions < 4.x does not provide information about the various storage engines supported. I mean, you cannot execute a SQL statement to get the list. Thus the names have to be hardcoded. For versions > 4.x, you can get it from an SQL query 😀 I dont remember which one though 😛

[Ritesh]

Issue added in the TO-DO list.

[Ritesh]

Hmmm 😮

This subject requires detailed study.

We will need to find out all commands similar to

Quote:

set session|global sql_mode = 'NO_ENGINE_SUBSTITUTION'

completely know their effect on the working of SQLyog.

I have added this in the TO-DO list but not with high priority 😀

[Ritesh]

There should be absolutely no problem importing a dump created from v3.23.x to v4.x.

I think there is a problem in the content of the dump file itself.

Can you attach the SQL dump file provided the data is not confidential? You can even mail them to [email protected].

[Ritesh]

It going along nice. You can expect a release next week 😀

[Ritesh]

The XML file created for SJA (its not SDA), will work only with SJA. You cannot execute the XML independently. You will need SJA to execute it.

You can send a mail to [email protected] regarding your requirements. We provide heavy discounts on bulk purchases of SJA.

[Ritesh]

Which version of MySQL are you running at the remote server?

With v4.1 and above, a table type is called Engine. Prior to that, it was called Type. Thus with an old MySQL server, the following query will fail:

create table (….) Engine = MyISAM

but this will work:

create table (….) Type = MyISAM

Just open the sql file in a text editor and replace all Engine to Type and everything will work.

As for the database not visible issue, are you sure that the database exists? You can find out by executing show databases. Do you see your database?

[Ritesh]

This issue has already been in fixed in v4.2.

[Ritesh]

For the sake of completion, you can rename a table by selecting the table in the Object Browser and pressing F2 to rename it 😀

[Ritesh]

Thanks for your suggestion.

We actually plan to improve upon this in v4.2.

[Ritesh]

This gets interesting. In HTTP Tunneling, SQLyog gets the data from the server in XML format.

It looks like, XML does not seem to correctly recognise leading and trailing whitespace in element data.

E.g. create a XML file with the following data:

Code:

    a

and open it in IE. It will always display it as:

Code:

a

The XML parser that we are using (IE XML parser for that matter too) interally seems to be doing just that. Thus during a sync we insert a instead of a and thus the checksum fails as a is different from [ ]a.

Thus syncing of a data with leading and trailing whitespace fails.

I are working on this issue and will keep you updated.

[Ritesh]

It is a known issue with HTTP Tunneling when we try to import large tables (with lot of rows). Since, HTTP is stateless we have to populate the whole table data at the source computer and due to limit specified in PHP configuration, it fails. 🙁

We plan to fix this issue in v4.3. Another SQLyog user has reported the same problem and thus requires more attention.

As of now, you will need to create a dump of database at source in SQL statements. Import it locally using Tool -> Import SQL Statements. Once, a locally copy of the db has been made, you can use Sync feature without any problem.

[Ritesh]

Does executing show databases list your database?

[Ritesh]

SQLyog will automatically reconnect if the last error is:

Lost connection during query

Are you getting a different error?

[Author]

Posts