[DonQuichote]

I am having the same problem (SQLyog Trial 6.0 beta4)

– New connection.

On the main tab, I leave the defaults. (which is ok. These credentials exist on the remote server)

On the SSH tab, I give the remote location, with the same username and password I would normally use with putty.

As local port, I choose 2202.

When I click “test connection”, I get the error “Connection lost during query (2013)”.

Further test. I cancel the open connection dialog and start putty.

I log in with the usual credentials.

I click “change settings…”->Tunnels.

I create a port forward: 127.0.0.1:3306 is forwarded to 2202.

I return to SQLyog and log in with a new connection, this time without enabling SSH and with port 2202.

No problems whatsoever. I see the databases and can access the data.

Am I doing anything wrong?

[DonQuichote]

uyuni wrote on May 6 2007, 02:06 PM:

… I have looked around in the internet but not found suitable software which can connect and synchronize between MySQL/Access/SQL-Server.

I think real sync to other databases (not only import and not only ODBC) is needed by quite some projects.

MS-Access can connect to both SQL server and MySQL. In fact, MS-Access can be used as a form engine or as a complete programming environment. If you desperately want to avoid ODBC (I would not know how you would connect to SQL server then), it would not surprise me if you could use the C library through API calls from Access VBA. Personally, I would prefer using ODBC to reinventing a wheel.

“Sync to other databases” can be quite a task. If you want to do that with Access, it is best to do so with pass-through queries and remember time of the last sync (both remote and local!). Off course, you would need timestamps on all the records that need to be synched (or some other means of knowing which records did change). And off course, you'd need to think about what you want in detail: If a record is changed in both MySQL and Access after the last known sync action, do you want a warning, a method to correct and compare things by hand, or should the latest change win?

[DonQuichote]

peterlaursen wrote on May 4 2007, 10:23 PM:

It is not plain easy! because when data are stored in a BLOB filed there is no file and no file extension, so there is no information about what program to use. You are welcome to detail …

I am aware of the absence of a file type. However, I can set the type (syntax highlighter) in my editor, even when the extension is missing or belongs to another file type.

The way I imagine the feature, you could right click on a text or blob field, select “edit with…” from the popup menu and give the path to an executable or select a path that was used before. That way, you could edit the blob field with any type of editor in just a few clicks, and do the type recognition yourself. SQLyog does not know the file type, but the user usually does.

It should be possible to monitor either file changes or the presence of the editor program. Checking for the presence of the editor itself has the drawback that the editor could be already open before the editing, and can handle multiple documents or even enforce only one instance to be present. Monitoring file change has the drawback of updating only upon the first save action, or waiting forever if nothing is changed.

If you are familiar with the program WinSCP (see http://winscp.net/ ), you have a nice example of how external editors can be called. There is more to an editor setting then just the path. for instance, you can configure if an editor is a multiple-document one. You could add an option to state a default extension for the temporary file with which it is called.

[DonQuichote]

peterlaursen wrote on Mar 28 2007, 12:09 PM:

First ensure that the data are STORED correctly on the server.

Export a table or database (as utf8 – use SQLyog or mysqldump as you like) and open in Notepad.

Check every non-ASCII/non-English character.

We have seen before that people has implemented a 'workaround' (encoding/decoding in the client) for data not really being stored as unicode. That we cannot replicate. But once data are correctly stored we should also display/save/edit them correctly.

Ah. There's the little bug. I used mysqldump to dump the table and it shows “€ 5” when viewed as unicode. All settings (during dump and for the server) point to utf-8, so there is really a storage problem in MySQL.

Thanks for helping me out.

For other people having the same problem:

I configure both the server (mysqld section) and the client (mysql section) in the my.ini file to use utf-8. However, this affects the server only and does NOT set the default encoding for a client connection. So the connections I opened from PHP defaulted to latin-1. SQLyog did not show this problem, as it sends a SET NAMES statement upon opening a connection. What is even more troubling is that this seems to affect modern (5.0) versions of MySQL only. And pre-4.1 versions do not even understand the SET NAMES command. Trying to stay compatible with different versions really gets hard this way…

So the solution is checking the MySQL version and sending the appropriate SET NAMES command if the version is >4.1.

[DonQuichote]

Rohit wrote on Mar 28 2007, 11:52 AM:

@DonQuichote:

Did you create the PHP page as a workaround because the Unicode features of SQLyog were not working as you had expected?

We really want to know if you are STILL not able to see data properly from your local server.

Well, yes. But that was when I was working with the previous versions (5.x). I could not find any other database frontend as well that gave me utf-8 compliance. The data gets sent as unicode and all the character set variables (I wish they had called them encoding variables) are pointing at utf-8. I have baretail running to see what is sent exactly and it is really utf-8. Off course, it could be that my MySQL version translates the encoding, but it should not do that (see variables posted earlier).

Extra test:

This really gets funny.

I type in the SQLyog window:

INSERT INTO ErrorLog(strMessage, tstOccurredAt) VALUES('€ 5',NOW());

and check the contents of the table ErrorLog. I see a euro sign. I check the MySQL query log. It also shows a euro sign. I view the page online and it shows a question mark. The page is viewed in utf-8 and I do no conversions in my code.

The querylog shows:

070330 9:57:48 6 Connect root@localhost on

6 Query use `HamerReport`

6 Query show variables like '%%character%%'

6 Query Set character_set_connection=utf8

6 Query Set character_set_results=utf8

6 Query Set character_set_client=utf8

…

070330 9:59:54 6 Query INSERT INTO ErrorLog(strMessage, tstOccurredAt) VALUES('€ 5',NOW())

With my workaround-page, I correct the question mark to a euro sign. I check the query log. It shows a euro sign. I check the contents of the table in SQLyog. It shows “€ 5”. I check the page online and see a euro sign.

The SQL log shows:

070330 10:02:38 12 Connect admin@localhost on

12 Init DB hamerreport

12 Query SHOW TABLES

12 Query SHOW FIELDS FROM ErrorLog

12 Query SELECT intErrorLogId, strMessage FROM ErrorLog ORDER BY strMessage

12 Query UPDATE ErrorLog SET strMessage='€ 5' WHERE intErrorLogId=1

Fearing this is a settings problem, I check my.ini. It shows:

default-character-set=utf8

in both the [mysql] and the [mysqld] sections, and all sorts of other quite specific settings that work (so I have the right file).

I hope this is of any help.

[DonQuichote]

peterlaursen wrote on Mar 27 2007, 04:50 PM:

I do not fully understand.

Do you have an issue with SQLyog 6.0 not displaying data form your local server correct?

I did not file a bug report, if that is what you mean. I also do not have much trouble with it, as this beta version is the first MySQL database frontend I know of that can handle encodings. Even phpMyAdmin does not do it right, even though it is web-based. So I solved the problem some time ago by creating a PHP page that allows me to make a change to any table value through the website.

I probably should have posted this in the bugs forum. Sorry.

[Author]

Posts