[peterlaursen]

That was nice to hear! 🙂

Those non-reproducable crashes have driven me crazy ..

.. even more than I always was 😀

L—O—N—G to verify that …

[peterlaursen]

OK, then 🙂

But if Les does not experience this agin, there is not need to go deeper into it.

I have no issue of the sort with connecting from SQLyog to ANY still-supported MySQL version.

Quote:

i.e. the MySQL is not running ..

MySQL on Windows is multithreaded and who knows what each thread does? Some threads might have been up and some down. SQLyog was still trying to connect (server did not refuse connection) and thus no 'can't connect' message. There is no time-out in direct connection, I believe?

After all the problem is gone. If Les experiences this again, he must write again.

If not reproducable no one can do anything about it anyway. And quite normal in my opinion to reboot the OS in case of such probelm with a service/a daemon (win/*nix). From time to time things just don't get loaded right.

[peterlaursen]

There is no problem other than his computer had 'dropped' the service. That happens on Windows. A reboot fixed it.

[peterlaursen]

Quote:

I mentioned this in B4 and was blown off as “not an issue”

What I wrote then, was that whether the scroll was up or down when first opening the GUI was no issue to me. But I did agree that expanding an item should not triger any change in scroll position. Sorry if I did not expres myself clear enough.

[peterlaursen]

Quote:

It seems a pc reboot fixed the problem.

I think then it is related to the OS-service.

[peterlaursen]

Quote:

how does sqlyog find mysql on my pc?

It simply probes the port (3306 by default) I think. If this port responds and returns a valid MySQL response then SQLyog must assume that there is a MySQL server behind it. There is no other way. Now the 'test connection' must return what it should .. however some other call executed by SQLyog at the beginning ot connection seems not to return anything that SQLyog can handle. Looks to me like it just waits for something that never happens!

I think we should let Ritesh take over here. To get closer to this you'll need to know exactly what the client code does. And this is beyond my reach and understanding 😆

However you may try if 'MySQL Administrator' has the same problem with connection !?

[peterlaursen]

Quote:

Mysql on my machine was installed from the “instant rails” package (in case that's relevant).

It could very well be. I have always been suspicious about those bundles. But I don't know anything particular about this one. What I know about instant rails is only what I just read here:

http://weblog.rubyonrails.com/archives/200…age-for-windows

When connecting SQLyog executes this SQL:

Quote:

Set names 'default'; — or whatever charset you choose from dropdown

set sql_mode='';

show databases;

Does this bundle include a command-line or another client from where you can do the same? At least you should be able to to so from a Ruby script.

If the MySQL code has been modified not to allow for 'set names' or returns something unexpected, I don't know what could happen.

BTW: Are you able to connect to other servers?

[peterlaursen]

Thanks for your extensive answer.

1) You were right. Choosing Turkish for use with non-unicode programs solved the issue with the editor! (must of course choose a Turkish script as well)

2) But it did not solve the issue with OBJECTS and HISTORY tab. Turkish here display as Icelandic (western mapping)! The Editor settings should take effect here too, I think. Did not solve for CREATE table and ALTER TABLE panes either. Could Editor settings apply here too (maybe it is not possible just like this in this type of grid object)?

3) 'Copy table to other host' (I rather did a copy to another database on the same host) changes data (pretty weird what happens here actually, when inspected in a HEX-editor!). @Ritesh. Could this not 'set names = ut8' when possible? Just like the export does? Or as an option? (Actually I request 'set names = binary' as an option too here and with DATA SYNC and BACKUP as well – because if MySQL versions are totally identical that will be the fastest !!!)

4) Yes!!! ALTER TABLE drops the charset information for the columns. Confirmed. Need a charset column in CREATE TABLE and ALTER TABLE pane.

@Nick .. again thanks for your contribution to this. I think it has been most valuable.

[peterlaursen]

Name of the company is WEBYOG

Name of the program is SQLYOG

[peterlaursen]

Not quite true what I wrote.

Actually the Editor can display all scripts of the font used.

You will have to do both:

1) Change windows keyboard setting

2) Change script in SQLyog 'preferences'.

See attached. It could be fun to try this with more different USB-keyboards connected at the same time. 😀

Now when I change back cyrillic gets garbled .. but as the SQL is latin-based I don't think that is a big issue.

But of course Comments should be legal with any character (Even Chinese!) as the program gets fully UNICODE compliant.

@Nick

Can you execute SQL written with Turkish keybord settings and Turkish script setting in SQLyog correctly?

[peterlaursen]

One issue more:

The 'script' settings in 'preferences' for font in the Editor do not work either. If I choose Turkish script and paste Nick's test2.sql into it, all the special Turkish accents are removed ('cedilla-s' becomes plain 's' etc.). This is not a display issue only because if I run the script from Editor pane characters without these accents are saved.

Also the ALTER TABLE removes accents from non-latin1 characters.

Finally the OBJECTS tab does not use the 'script' setting in 'preferences. Nick's Turkish characters are displayed as Icelandic (latin1-mapping) here (comments in table definition).

Looks like a VERY BIG revamp of the Editor code (and more) – or maybe a completely new one – is needed for 5.2 too.

Finally I upload the test3.sql again. First file seems to be damaged.

[peterlaursen]

aha … now see attached …

If I use 'latin5' for the connection AND from 'preferences' choose Turkish script for the DATA/RESULT pane I can actually display it correctly. Most surprisingly I can enter rows with Danish characters æøå in all three columns – export and import again. And even the 'latin5' column does not garbage those characters. Are they mapped with the Türkish script too? @Nick – you know?

But it has no efect on the keyboard in SQLyog. The Windows keyboard configuration does not work in SQLyog. i can easily swith from Turksih to Danish keyboard layout in Notepad for instance – but not in SQLyog. It does not have effect.

BTW:

I request that font settings dialogue should display the script used.

[peterlaursen]

'yog' is a word in the ancient Indian language SANSKRIT. The SANSKRIT languge was the language of the first indo-arian high culture that developed in North India more than 4000 years ago. The famous Veda's are written in Sanskrit. The language is still spoken by millions of people, mostly people with religious or cultural interests. Quite a lot of westernes learned it too.

The short version: A 'yog' is a person. He is what a person ideally should be: hardworking, honest, responsible, smart etc. What he does, he does not for himself but for for the world.

The long version: Let Ritesh … or search google on 'sanskrit +yog'.

'yog' can be a stand-alone word or it can be used for prefixing and suffixing other worlds – this giving meaning to other words – or other words giving meaning to the word 'yog'. I think you can translate 'SQLyog' yourself now? 🙂

I think you may compare sanskrit 'yog' with latin concept of 'pater familias' .. They both picture the IDEAL of a person! But in two different cultural contexts!

[peterlaursen]

1st:

Quote:

Error in the job file: error document empty, at line 13″ or “SOURCE server information not available”

.. well

1) is the source server available?

2) Do you have write privilege to the folder where the SJA resides?

2nd:

The file that is save is the XML jobfile like jobfile.xml. You can use it 2 ways:

>>1) Open if from 1st screen of the Sync wizard

>>2) use it with SJA from commandline “sja jobfile.xml”.

From commandline you can also specify a logfile and session file with l and s parameters like “sja jobfile.xml ssessionfile.xml llogfile.txt”. That is for use in situations where user does not have write privilege to installation folder.

[peterlaursen]

@nick

Thanks .. very useful I believe!

first a reply: to “I couldn't find any reference to the utf8-option mentioned in the last post”

This is a checkbox on the latest screen of the backup 'powertool' Wizard of BETA5.

Another new thing is that when exporting from MySQL 4.1 ++the simple 'export' option of BETA5 encodes as utf-8. So a simple export is fine as well. So file test2.sql will do!

I am a little confused.

test1.sql does not have character set definitions in the columns definition – test2.sql has.

But test1 has comments – test2 has not.

… Looks like two different tables / two different tries? Could you explain? How did you create test1.sql? With what program versions (MySQL and SQLyog)?

But basically test2.sql was what I was after. I wanted to see if those characteres displayed correctly if I imported them in SQLyog. That was why I had a utf8, and ucs2 and a latin5 column (this was the important point!). They don't – no matter what character set i choose for the connection. A specila note on this: If I choose 'latin5' for the connection the data are handled correctly internally – however displayed using the'western' mapping of the fonts chosen. With this mapping most of your Turkish characters are mapped to Icelandic characters! See attached .jpg

And that is too bad, because even Notepad displys all of those characters correctly (also the one from the latin5 column) – even on my Danish Windows XP. However I can repeatedly import the file, export the table and and characters remain OK! So the server-client interface is OK as far as charset information is concerned, however the fonts rendering library of SQLyog is not up to date (supports only one localisation and that is an unnecessary restriction with a NT-based system!) – or whatever it is that is the problem here. This is a rendering issue! Even conversion of the SQLyog codebase to UNICODE would not solve this I think!

In a HEX editor I can verify that all data keep being OK after several in-outs to/from SQLyog.

Also (what surprises me). Comments from test1.sql are readable in Notepad here. Even though table default is 'latin1'. In a HEX-editor I can see that comments are utf8 encoded. Data are not in this file! Actually I can copy comments from test1.sql to test.2 sql with the clipboard and everything is still OK – except for the display in SQLyog. So looks like MySQL 4.1 always stores comments in utf8 – as suggested by somebody else suggested in another thread!

@Ritesh. I think that is is important that you spend 5 minutes with this and understand it. Especially get the test2.sql, open it in Notepad and import into SQLyog and compare! Also read the last 20 lines here careully .. 😀

Attached file test3.sql is identical to test2.sql except that comments from test1.sql added! Windows XP has no problems in handling this character information!

Those crashes in DATA pane makes me crazy! But I had a few too! also with Beta5 – however it is much more stable here than was beta4.

[Author]

Posts