[peterlaursen]

No we do not quite understand. You are welcome to detail it.

Is it reproducable? Or did it happen only once?

Can you give details about the two connections ?

Quote:

I'm just a guy whose intentions are good

Oh Lord, don't let me be misunderstood

(The Animals 40 years ago .. and nothing changed 🙂 )

[peterlaursen]

The bug was in the compiled C-code and not in the tunneller.  It is fixed now.

[peterlaursen]

Code:

1) For mysql_connect(), you need to publish “SET NAMES (Your Character Code)” everytime after reconnecting to MYSQL.

We do .. but not if charset is (default)

this function is called every time:

Code:

[code]function SetName ( $mysql )
{
global $charset;
WriteLog ( “Enter SetName” );
if ( $charset === NULL )
return;
$query = 'SET NAMES ' . $charset;
if ($charset!=”[default]”) {
yog_mysql_query ( $query, $mysql );
}
WriteLog ( “Exit SetName” );
return;
}

[/code]

note:

Quote:

if ($charset!=”[default]”)

We have reproduced the issue with 'copy ..' using HTTP-tunnel, but this is too simple!

And still NEVER use the 'default' setting in the connections manager when connecting to a server haveing Utf8/ucs2 as default – except for migration of Unicode data.

[peterlaursen]

Thanks!

maybe you are right both of you, and I was wrong!

we will study this!

[peterlaursen]

You cannot do this in SQLyog.  Dates in MySQL is stored in the format of YYYY-MM-DD, and a client like SQLyog cannot change this.

With web applications I think it is most common to use different (PHP/javascript) (string) functions to extract year, month and day and builld you own display format.

However in SQL what you can is described here:

http://dev.mysql.com/doc/refman/5.0/en/dat…-functions.html

note the DATA_FORMAT() function and the lot for formatting string options available!

An example:

Code:

set @the_current_date = '2007-02-16';
select date_format(@the_current_date,'%e-%m-%Y');
— this returns '16-02-2007'

There is no GUI functionality for this – you will need to write the SQL yourself.

Also note that the above example (with user variables) will not work with HTTP tunnelling unless you use SQLyog 5.23 with php_mysqli() ).

[peterlaursen]

I am 99.9% sure that this is not related to tunelling.  Same thing would happen with direct connections.

'copy .. to other …' creates a new connection.  Maybe there is an issue that this new connection uses 'default' charset as 'default'.  And that would fail with uft8 data.

I'll ask a developer to look detailed into this!

[peterlaursen]

Please try 5.23 RC2 (just uploaded) and report results.

[peterlaursen]

I am not sure I understand you notation and the term 'double key'.

An index that uses more columns?

You want to use the 'name' and 'code' columns for that 'key' ??

If you want it to be a PRIMARY key you do from 'ALTER TABLE' – just check both columns

If it is not a PRIMARY key but just a plain index you to from 'manage indexes'.

Both are available from the table context menu.

[peterlaursen]

BTW: always tell the program version!

You should read this FAQ: http://webyog.com/faq/34_102_en.html

You should NOT select neither 'default' or 'utf8' for the connection – not to a server with utf8 data either. Use the charset that corresponds to you windows localisation ('latin1' or whatever)!

I am 99% sure that I understand now. And if I understand correct this is not at all HTTP-releated, but is ude to the fact that currently SQLyog uses ANSI internally. Same would occur with direct connection(s). With hindsight we should not have given the 'utf8' or 'ucs2' options in the connection manager. Because SQLyog cannaot handle a stream of UNICODE data. Only the Migration Tool can (and needs a SET NAMES UTF8 when importing Unicode data from an ODBC source).

As we release 5.3 (that will use UNICODE internally) soon things will become easier! Easier to perform and easier to understand!

[peterlaursen]

The SET NAMES statement is sent by the tunneller for every single statement.

This PHP funticon is being caled every time!  So that is not the problem.

Instead of you guessing the reason for this you could give us a test case so that we can solve it! 😉

“So when you have two servers with default connection set to latin1, the source (tunnel) send the data as latin1 but the local connection is set to utf8.”  I do not uderstand.  You have two remote servers (latin1) and one local (utf8) – was that what you meant ??

One idea: create the database that you copy to like before copying data:

Code:

CREATE DATABASE mydb DEFAULT CHARSET UTF8

(not possible from the GUI at this moment unfortunately)

I am not sure that this is related to HTTP at all, I think it is rather a limitation with the 'copy database/table' functionality … but please explain more in detail! 

[peterlaursen]

1) the sever architecture(s) are different (information_schema. system variables, implementation of SP)'s triggers, dta type differences etc.)

2) the SQL 'dialects' are different. Most important MySQL SHOW statement is not supported by MS SQL.

3) the is no parallel to the MySQL C-API

so every byte of code related to how to communicate with the server would have to be rewritten.

However what code there is defining the GUI would still mostly be usable.

So .. lets's say that 33% – 50% of the current code would go into a version for any other database server.

We have no such plans!

[peterlaursen]

two ways (at least):

1) With MySQL 5.1 and 5.2 you can create an EVENT.  You can only send one query as an event, but if you put it all into one store proced

re and all you need to do is the create an EVENT executing 'CALL my_sp()'

2) With all MySQL versions you can let SQLyog/SJA Notifications do.  Notifications Services is an ENTERPRISE feature only.  Schedule the job to run from the client (of course client machine must then be on!). Now try starting the wizard from the 'powertools' menu and you will probably find out. You can add an unlimited number of queries and won't need to run inside a SP.

[peterlaursen]

We belive we fixed this now.

Downloads from:

http://www.webyog.com/downloads/betas/not_…d/SQLyog523.exe (COMMUNITY)

http://www.webyog.com/downloads/betas/not_…QLyog523Ent.exe (REGISTERED VERSION)

http://www.webyog.com/downloads/betas/not_…523EntTrial.exe (ENTERPRISE TRIAL).

Feedback appreciated!

[peterlaursen]

We belive we fixed this now.

Downloads from:

http://www.webyog.com/downloads/betas/not_…d/SQLyog523.exe (COMMUNITY)

http://www.webyog.com/downloads/betas/not_…QLyog523Ent.exe (REGISTERED VERSION)

http://www.webyog.com/downloads/betas/not_…523EntTrial.exe (ENTERPRISE TRIAL).

Feedback appreciated!

[peterlaursen]

We recently introduced a new export option.  there are now 2:

the 'DUMP' option

the 'export data' option

Try using the DUMP option.  And read the changlogs/notes for 5.22:  

— Added 'export data as SQL' as an option. Note: this feature is NOT intended for backup purposes as only INSERT (DATA) statements and a very simple CREATE statement will be created.

I do not think it should export views unless you explicitly export a a view!  We will dixuss on Monday! 

[Author]

Posts