[Ritesh]

I have added this in the TO-DO list.

[Ritesh]

shoyu wrote on Oct 26 2005, 10:16 AM:

Hello,

This is a bug with V4.2RC1:

Problem:

It seems that special SQL characters like ' are not managed in the comment column of the “alter table…”.

If you type Nombre d'années (french) you have an error when you validate.

Solution for the moment: You have to type Nombre d''années.

Cheers.

Shoyu

[post=”7705″]<{POST_SNAPBACK}>[/post]

This is correct. You will need to escape ' with a .

[Ritesh]

This is a known issue. We plan to completely re-implement Personal Folders in one of the future versions of SQLyog.

[Ritesh]

This is very strange. We don't touch Personal Folders directory on upgrading. We only remove the folder during uninstallation.

[Ritesh]

Did you download the latest v4.2 RC?

This issue was fixed in the latest version of SQLyog v4.2 RC.

More info at: http://www.webyog.com/forums/index.php?sho…st=0&#entry7693

[Ritesh]

Bah, I didnt see the date 😀

[Ritesh]

peterlaursen wrote on Oct 21 2005, 07:15 AM:

See atached.

The databases are on SUSE linux 10 with MySQL 5.0.13 on one conputer on my network.  Obviously SQLyog (form a windows computer on the network) offers to sync.  However the databases are not sync'ed – indsted the err msg “Could not get FIELD information for '`TableName1`' in the TARGET database” .  Obviously because there is not `TableName1` but a `tablename1`.

[post=”7666″]<{POST_SNAPBACK}>[/post]

This is correct. Its an internal SJA error which means a particular column information for a table was not found in the TARGET server.

peterlaursen wrote on Oct 21 2005, 08:01 AM:

With tunnelling SJA crashes with a similar setup.  See pic.

Tested on my webhost a new local Linux installation.

(yeah I managed to rudimentarily set up Apache + php in 10 minutes  😀 )

[post=”7667″]<{POST_SNAPBACK}>[/post]

Bug confirmed and has already been fixed in BETA 6 development tree. We were able to reproduce it yesterday on our Linux box 🙂

peterlaursen wrote on Oct 22 2005, 07:48 PM:

Some more research:

Now that I got a local LINUX working I am able to research some more into issues like this one.  I am also able to run SJA for LINUX.

1) I changed data a little bit in both.  DATA sync was perfect with SJA for LINUX as well as SJA for Windows.

Correct. SJA is not effected by change in case of data. For SJA, A and a in data is different.

peterlaursen wrote on Oct 22 2005, 07:48 PM:

2) Now changed tablenames to `TableName1` on both hosts. It results in errors

“Error No. 1050 Table 'tablename1' already exists” or

“Could not get FIELD information for '`tablename1`' in the SOURCE database”

I believe that the first is a MySQL error and the latter an internal SqLyog error ?

Correct. The reason for the above is error is that Tablename1 which existed in source does not exist in target.

peterlaursen wrote on Oct 22 2005, 07:48 PM:

3) Next I renamed both tables to `tablename1` and renamed column`t` to `T` (with ALTER TABLE) on the windows host .  A sync with SJA for LINUX returns the error “Column NAME mismatch for '`tablename1`”.  An internal SQLyog error, I think? A sync with SJA from Windows runs successfylly.

SJA for Windows is case insensitive but SJA for Linux is case sensitive and thus the difference.

peterlaursen wrote on Oct 22 2005, 07:48 PM:

5) It is correct that the STRUCT-SYNC tool completely disregards CASES for TABLE names and and COLUMN names.

We plan to fix this issue in one of the future versions of SQLyog.

peterlaursen wrote on Oct 22 2005, 07:48 PM:

6) Now I created an empty database TEST on LINUX (the `test`databae is still there).  The SQLyog GUI cannot distinguish between `test` and `TEST` – lots of GUI errors occur.  For instance when trying to copy  `test` to `TEST`,  `TEST` does not appear on the list of all.  And when opening a new connection, SQLyog is fooled to believe that `tablename1`  exists in both  `test` and `TEST`, but when trying to open `TEST`,`tablename1`  a MySQL error is this played (of course).  “Cannot fetch ….”)

7) The struct sync tool now only displays `TEST` not `test` on the LINUX host.

Since SQLyog does not consider case for db/table/column names, there are some issues related to it. I have added it in the TO-DO list.

[Ritesh]

walkman wrote on May 24 2005, 04:18 PM:

I get a 1064 error when I try to copy tables from local to server.

It turns out that my local instance is 4.1.9 & my server instance that I'm copying to is 4.0.18

Is there a way around this error?

Thanks.

[post=”5646″]<{POST_SNAPBACK}>[/post]

This issue has already been fixed in 4.2 BETA 6 development tree. Now SQLyog will check the source and target MySQL server and if required will construct the CREATE TABLE statement itself. It will not use the CREATE TABLE statement returned by:

Code:

show create table tablename

PS: SQLyog will still use SHOW CREATE TABLE SQL in Export As SQL Statements option as we dont know the TARGET MySQL server version.

[Ritesh]

Shadow wrote on May 25 2005, 08:58 AM:

And do not use InnoDB because its engine has been changed in 4.1.1 by adding multiple namspace support!

[post=”5671″]<{POST_SNAPBACK}>[/post]

Nice to have you back Shadow 🙂

[Ritesh]

peterlaursen wrote on Oct 23 2005, 07:55 AM:

FAQtured  😀

http://www.webyog.com/faq/5_71_en.html

[post=”7677″]<{POST_SNAPBACK}>[/post]

Nice one 🙂

[Ritesh]

We actually have some customers who use SQLyog with WINE without any problem.

Never been able to document it though 😀 Maybe we should document it in the FAQ for people who are looking for a Linux version of SQLyog 🙂

[Ritesh]

Connect to your MySQL server. Select the database in the object browser and use:

Db -> Export database as SQL dump

[Ritesh]

This is very strange as we dont have any hardcoded port number programmed in SJA.

[Ritesh]

When you are using SSH Tunneling, you create a background tunnel process which listens on a local port and forwards all the details to the actual MySQL server. SJA connects to host and port provided in host and port element.

You can assign the local port for the SSH Tunneler in the “Port” element of the XML schema.

If you specify the same local port for the SSH Tunneling as your local MySQL port, the data are sent to the MySQL server rather then the SSH process. Thus instead of connecting to you remote server it connects to your local server.

Just assign port 3310 (provided its not used by any other application) for the local port and try the connection.

[Ritesh]

This is very strange. When we tried the same in our Linux box, the process stopped after giving out the error:

Table does not exists

[Author]

Posts