[peterlaursen]

well …

With SQLyog Enterprise you can use Notifications Services to execute SQL with the SJA. You can build a batch file with more SJA-instances as explained here: http://www.webyog.com/faq/27_35_en.html . Each instance of course can connect to different servers.

The batch file can be scheduled with the built-in or a third-party scheduler

The .SQL files(s) is/are not executable(s) themselves and can't be scheduled!

[peterlaursen]

Let me answer this too:

Quote:

Why doesn't structure sync simply use the results from 'SHOW CREATE TABLE' when it needs to create a new table

Because the STRUCTURE SYNC tool is designed to work across different MySQL versions, and 'Create Table' syntax varies with different MySQL versions

[peterlaursen]

Quote:

if it took all of your Japanese text files …

You are not supposed to work with SQLyog and multibyte charsets as of now!

But yes .. if you are not aware you may destroy data.

I would expect any user to have a backup before doing such operation!

The syntax/implementation of charsets varies across different MySQL versions, so your examples will have to be 'expanded' to fit all (as SQLyog supports all MySQL versions from 3.23). But you probably know this.

I can follow your idea that if a charset is specified with a column or a table it should be sync'ed.

However if no charset is specified with columns (or tables) and you are syncing across servers having different defaults then I think the sync should not 'bring over' the charset from source to target. That would result in 'mixed' databases or tables. And that is what I think most users don't want. At least I would request a user approval of this. Ideally a popup should appear for user to decide what to do.

But it is true that this charset/collation discussion is related to the FK-sync as well.

I think now we should wait for a response from the development team. They will need a few hours to consider things. But thanks for your observations and considerations.

[peterlaursen]

OK – thanks …

I understand now!

It is an issue with the newly introduced FK-sync, I believe.

[peterlaursen]

Just let me add that as syncing of FK's is quite new with SQLyo 5.1 there could very well be some issues. Probably only a few people have tested this.

So please detail your examples!

[peterlaursen]

I agrre that there is at least a documentation issue! I still think that your situation and need is atypical. But a warning of some kind would be nice.

This:

Quote:

I set the collation in one column to be latin1, another to be geostd8, yet another to be hebrew

I think mixing charsets like that in a table is not wise (although possible and legal). I never think a GUI tool like SQLyog will be able to handle this a reasonable way (for the simple reason that you have one and only one localized Windows and only one localized keyboard). I would recommend that you make more tables – each with their charsets – and use UNIONs and JOINs to query more when you need. Actually as of now mixing tables with different charset in the same database is not without problems. That will be better with next BETA. And I shall request (again) that each time SQLyog sends a 'use ..' statement it also should send a 'set character_set_result …' —

BTW: If you'd been follwing this Forum for a while you'd know that I personally have been 'pushing' quite a lot for putting focus on charset and localization issues – for more than 2 years! Give it two months more …

[peterlaursen]

UI:

1) No issue in my opinion.

2) Agree that this should be fixed

3) I don't understand! Where do you see that! I don't find anything garbled here! Could you provide two 'create statements' to reproduce this?

4) Same as 3). It would be easier if you provided a reproducable example.

SQL:

1) No issue in my opinion. There are dozens of different ways.

2) I answered this ..

3) Same a s 2) above. Please provide a 'reproducable test case' in detail. I can't reproduce with my data.

4) No issue in my opinion. There are dozens of different ways.

[peterlaursen]

1)

Quote:

The table on the source server was 'DEFAULT CHARSET=utf8', and on the source server they ended up being latin1 (the default for the server).

This is unclear to me. I would expect “on the target server they ended up being latin1..”. A typo? :huh:

I think most people would not bring the charset from source to target when syncing between two databases having different charsets. However that could be an option. Or a warning/a message could be printed.

But it is always possible to edit the CREATE and ALTER statements.

2)

I don't understand!? It generates a quite normal CREATE SQL statement herre ?

[peterlaursen]

What is the MySQL version?

Version 3.23 does not hide metadata for hidden data.

[peterlaursen]

@jrossiter

Please search the Forums and the FAQ!

A little search would tell you that full unicode compliance is planned for SQLyog 5.2.

Cool down!

[peterlaursen]

If this is not what you need you will need to wait for someone else that knows more about linux than I do!

[peterlaursen]

I have only tlittle experience with this.

But if I have a 'sync' file containing

Code:

sja myjob.xml

then I can simply execute

Code:

./sync

or

Code:

/path/sync/

from command line or as a cronjob on SuSE 10.

I don't know about the way you are trying to do things. Why do you want to create a file in /bin/bash? Do you need to?

[peterlaursen]

Quote:

#/home/my_user/sja /home/my_user/sja/sync_test.xml

I am surprised that this works! 'sja' is both a folder and a file (the executable) – if I understand you right. So the path to the executable must be #/home/my_user/sja/sja I think! (sja * 2: first sja-folder, next sja-file)

So what happens with

Quote:

#/home/my_user/sja/sja /home/my_user/sja/sync_test.xml

in the /bin/bash/sync file?

And if there is only a sja file and not a sja folder it must be

Quote:

#/home/my_user/sja /home/my_user/sync_test.xml

Also:

why not simply put the 'sync' file in your own folder tree and start it with /path/sync or just ./sync

[peterlaursen]

Same thing applies to EVENTS as they also allow for BEGIN .. END's

Actually – even if you copy from HISTORY to SQL-PANE you'll need to add “;”s yourself. No need for that – it could be written to history and will do no harm. For permanent storage in 'favorites', use with SP's etc .. people would want not to have the TIME information. So it should be possible to turn it off.

[peterlaursen]

nono, I think … <_< If someone wants to put a lot of ordinary SQL in a Create SP or Create Triger statement it runs somewhat like: DELIMITER $$; CREATE procedure … (….) BEGIN ordinary_SQL_1; — with semicolon! ordinary_SQL_2; ordinary_SQL_3; etc END$$ DELIMITER ;$$ Then they can copy structure from an existing database, do all the changes from GUI on that copy, record 'ordinary_SQL_n's' to HISTORY and copy from HISTORY into Create SP or Create Trigger statement. It simply takes the use of semicolon “;” “;” is always used between BEGIN .. END (and inside cursors too), other DELIMITERS is outside BEGIN .. END

That could be first step in a SP builder GUI (where the copy structure could be transparent to user and where SQL is directly inserted to CREATE PROCEDURE bypassing HISTORY)

[Author]

Posts