[peterlaursen]

You found a pretty old discussion here! You could have found a more recent one only about a week old.

There not not been developed on this yet.

Now we did manage to get SSL certificates into HTTPS tunnelling to be released with beta4 later today.

So I think we should pay attention to KEY authentication with SSH tunnelling next!

But basically I think it is there is the PLINK code that we use – we only need to interface to it.

Let us finish beta4 today and revert back 2row or monday with a reply on this!

[peterlaursen]

1) Nowhere! http://webyog.com/faq/33_128_en.html

… if you are interested in 'more stability' stick to latest versions! But be careful with betas of course! And you may also decide to wait a few weeks to upgrade when a new major version is out, if you do not fully trust the beta testing.

2) You purchase from here:

http://webyog.com/en/buy_sqlyog_enterprise.php

Thanks for your interest in in 'vintage SQLyog' … 😀

[peterlaursen]

“5.2 Beta 1”

there have been some crashes fixed in the BETA tree. In particular between beta1 and beta2. So please upgrade to beta3 and (when available) beta4. It will likely be 2row – thursday.

[peterlaursen]

We have an non-released ´pre-beta' 4 here:

http://www.webyog.com/downloads/betas/not_…SQLyog52Ent.exe

they tell me the the issue with certificates and HTTPS is solved. Can you verify this on your servers?

[peterlaursen]

Can you use anything from here:

http://webyog.com/faq/27_34_en.html

[peterlaursen]

exactly!

It is fixed in the development tree now.

we will probably release beta4 tonight.

[peterlaursen]

@Tom .. nothing decided yet. And it won't be in 5.2

But my personal idea is a small icon on the TAB itself that works like a 'switch' sticky/unsticky.

[peterlaursen]

… but you really SHOULD have a primary key in the table because without a PK the WHERE-condition must include all columns. With such WHERE MySQL cannot use indexes at all and with some data in the database an update can be very slow.

BTW: do you have any particular reason to use TEXTs for all fields and not VARCHARS ?

[peterlaursen]

What we can reproduce with this schema is that if more rows have the same value for the numerical field and you change that numerical field (not a text filed) SQLyog sends SQL like

Code:

update `tbl_requetes` set `Req_ID`='abc',`Req_Sql`='def', `Req_Param`='ghi' ,`Req_Description`='jkl' ,`Req_Type`='2' ,`Req_Libelle`='mno' where `Req_Type`='1';

what results in all rows having `Req_Type`='1' to become updated even if the text fileds are not identical.

The where-clause:

Code:

where `Req_Type`='1';

would be OK if that field was a PK. But it is not and it is a bug.

[peterlaursen]

not a new request!

It is not there and not hiding! We are considering a feature to make a RESULT-tab 'sticky', so that it will not disappear when you are executing a new query.

[peterlaursen]

Actually we could consider to add an option to 'add link to a folder' from mananage favorites ….

[peterlaursen]

BTW: you should consider upgrading SQLyog. At least when 5.2 gets FINAL.

hello ..

I also want to see

Code:

SHOW variables LIKE '%character%';

on BOTH hosts! the one you showed me was that source or target?

[peterlaursen]

I simply think that your special apostrophe gets stored/encoded as HEX(E2 80 99). That displays as '’' in latin1. And your source PHP understands to decode this – but not on the target.

Now .. you could try to change the connection string in the PHP script on source to point to the target (if you can connect). What does it now display as?

Try

Code:

SELECT HEX(yourcolumn) from yourtable where into outfile ;

zip the file and attach it here and lets us see the HEX values of how that apostrophe is stored!

(don't forget to quote the file name and escape ''s in file names like 'c:\test.txt')

or just

Code:

SELECT HEX(yourcolumn) from yourtable where ;

to display the HEX-values on the screen

[peterlaursen]

It will not work with communication in a browser here. The webserver/browser does encoding of their own!

zip everything and attach that you want to communicate! I need to investigate every single character in a HEX-editor!

But I think that 'latin1' as charset is a bad choice here. I would try using utf8 and disable this PHP feature if possible! Or maybe even better save as VARBINARY/BINARY/BLOB and not VARCHAR/CHAR/TEXT (and so simply store as BYTES, not CHARACTERS). It likely works OK with PHP but as soon as you use other clients ….

I'll concentrate on the sync issue as it is 'our business'.

You write: “The issue that I run into is that when I export that data it exports just as it is stored. But when the browser looks at the same record on the target database it just shows the garbage instead of converting it into an apostrophe like it does on the source database.”

I do not think it saves as stored! SQLyog export tool does utf8-encoding! But if you import it should converted back.

First:

=====

are you

1) dumping/restoring

2) COPYing

3) or SYNCing?

With DATA SYNC there should be no issue/difference if the same charset is used on source and target!

Second:

======

Is the source and target database on the same server? if not are you then sure that webserver/PHP configuration is identical?

[peterlaursen]

Not possible. The path is hardcoded into the program. It is not a setting in the .ini or the registry.

What you CAN do however is to store your 'favorites' as SQL on any mapped (network) drive and use the 'file:// ..' option on the individual machines linking to the folder containing the scripts themselves.

You will need to create only one local 'favorites' folder and distribute to all machines. But the network drive must be mapped to the same drive letter on all machines.

And this way you can of course have both 'shared favorites' and 'personal favorites'

[Author]

Posts