[Ritesh]

Can you provide me with your table structure and how many rows are there in the table?

[Ritesh]

This is strange. We have never come across an issue like this.

Can you do one thing? Copy the sqlyog.ini from the installation directory of FREE version and copy it to the installation version of Enterprise edition. Does that work?

[Ritesh]

😀

[Ritesh]

Fixed in RC development tree.

[Ritesh]

We have fixed many crashing bugs regarding DATA TAB in the last two betas and current RC1 which is under development.

Do you face the crashing bug other than data tab too?

[Ritesh]

After reading the whole explanation, I think all the issues can be summarised into the following points:

ALTER TABLE drops the charset information for the columns.

We have decided to support charset information from RC2 in CREATE TABLE, ALTER TABLE and REORDER COLUMN options.

Copy table to another host ( we are not using UTF8 ).

Starting from v5.1 RC1, SQLyog will issue the command “SET NAMES=utf8”, in both the source and target before exporting data. This will allow an user to export/copy any kind of data to and from MySQL. PS: Both the source and target has to be v4.1 and above for SQLyog to use utf8.

This feature has already been implemented in RC1 development tree and I was able to copy TURKISH characters stored as utf8.

The editor does not support other char set ……in history and objects tabs….

This is a known issue and we will fix it in v5.2 only when we provide complete support for uc2 and multilingual in v5.2.

Adding comments using the alter table converted turkish chars to question marks.

This is a known issue and we will fix it in v5.2 only when we provide complete support for uc2 and multilingual in v5.2.

[Ritesh]

SQLyog Job Agent 4.0 is pretty old and we have had lot of bug fixes after that.

Did you try the sync using the latest SJA v5.x?

If it is still giving errors then can you send me sample data so that we can reproduce the problem?

[Ritesh]

Indeed you can have both the versions installed on the same system at the same time.

Are you sure you are providing the correct and same connection info for both the versions? The error seems to be that you are not providing the correct host/domain name.

Can you disable your firewall and try once again?

[Ritesh]

This was a bug and has been fixed in RC development tree.

[Ritesh]

I think your problem is same as: http://www.webyog.com/forums/index.php?showtopic=2041.

Can you reboot your MySQL server and retry?

Also, you will need to tell me your MySQL version?

[Ritesh]

Bug fixed in RC(1) development tree.

[Ritesh]

I plan to implement this in either RC1 or RC2.

[Ritesh]

Thank you @Nick and @stom2005. We were able to reproduce this error and this has been fixed in the v5.1 RC development tree. While investigating this bug, we fixed another bug in DATA TAB.

[Ritesh]

jrossiter wrote on Apr 3 2006, 01:52 AM:

Don't send the scroll to the bottom of the window

This occurs when the UI is first loaded, as well as on every single folder action. Closing or opening a folder sends the scroll to the bottom of the window. I mentioned this in B4 and was blown off as “not an issue”, but I'm sorry… for usability, this is serious. It makes the SS UI extremely difficult to use.

I am not able to reproduce the problem while opening a folder. It indeed scrolls down to the bottom on closing of a folder and this will be fixed in v5.1 RC.

Quote:

Don't pre-expand the folders in the SS UI

It makes the SS UI really difficult to use when you have large databases. The Pre-5.1 behavior of closed folders is much more user friendly.

(For instance, I have a DB with > 50 tables that I use on a daily basis and sync fairly frequently)

I have put this issue in the TO-DO list for v5.2.

[Ritesh]

peterlaursen wrote on Apr 2 2006, 06:17 PM:

1) Export

* 'Create Bulk insert statements' simply does not work!

* There is no CHUNK option. I think there was in beta 4. Is that intended that is is removed?

2) Backup 'powertool'

* Unchecking CHUNKs creates a BULKs of one line only ??? (or is it a CHUNK of one line only that is created?)

* When I choose a certain BULK setting the BULK settings become quite different (much smaller). For instance if I chose 100000 Bytes each BULK become between 2-3 KB.

Both:

* formatting the dump file: Additional blanks lines often occur where they should not and don't occur where they should!!

Actually I am a little bit uncertain about the stauts of this thing. Whether it is supposed to be fixed or not in B5. But anyway: take it as a reminder that it is not …

BTW: I request (again) that BULKs are specified in KB not B(yte). The latter is ridiculous in my opinion! 🙂

Regarding point 1, 1a is a bug and has fixed in RC development tree. 1b, there is a CHUNK feature but its called “LIMIT ROWS” in the Preference window. It does not have any effect on direct connection. It is applicable to HTTP Tunneling though. If you export a huge table then SQLyog will get data in LIMITS as specified by the user (1000 rows by default if the user does not specify it) from the server and dump it. Its useful when you have a big table and your ISP has put a limit to the memory usage for PHP.

Both the issues in point 2 are bug and have already been fixed in RC development tree.

Quote:

Both:

* formatting the dump file: Additional blanks lines often occur where they should not and don't occur where they should!!

Can you explain this a little more? A sample would be nice.

[Author]

Posts