[peterlaursen]

@nicmar:

'Saved connections' are save in the SQLyog ini-file int the installation directory!

'Favorites' are SQL-scripts and are saved in 'Application Data' folder

[peterlaursen]

I have just been experimenting with installing SQLyog on more user accounts.

I did some installs and uninstalls, and the 'Favorites' were not deleted by the uninstaller.

But I did not have any 'Personal' folder in the 'Favorites' folder.

Did you get closer to the problem?

[peterlaursen]

YES and NO …

If each user install his copy of SQLyog enterrpise in each their folder (sqlyog_me & sqlyog_you) they can both be registered. If 2nd user installs 'over' the install made by 1st user it cannot. However SQLyog takes only about 10 MB disk space so this is no big issue to have two copies installed.

@ritesh: any chance to put the 'install for all users' option in the installer script with 5.1? (then fix the WINE issue with the installer script an the keywords DB too 'in one smash' <_< ) This issue also means that only 'Administrators' can install, register and use SQLyog Enterprise. Now a lot of companies don't allow users to be 'Administrators'. With the 'install for all users' option an 'Administrator' would be able to install for 'Ordinary Users'.

[peterlaursen]

And … If I understand correctly .. ,-)

that would also be possible to have special characters displayed when choosing utf8 from connections manager with some future 5.1 release.

You wrote: “We plan to support display of data which is stored in utf8 but are of one byte in BETA 6” Only ASCII characters are one byte only in utf8! 🙂

Ok .. let us see what it comes out like!

[peterlaursen]

I can confirm taborini's issue.

I tried to use SQLyog Enterprise 5 from another User Account than the one that I normally use. It prompted for the registration details, and DID NOT accpet those that are used on first account.

Would it do the trick to install once more as the other user?

[peterlaursen]

1)+2) OK .. al understood. But this ” It's hard to try different versions cause there are different tunnel-php-files.” You may rename them and have more 'variants' if you can edit the PHP-code to specific needs or need versions for different SJA/SQLyog versions! I always rename the 'SQLtogTunnelBETA.php' with BETA versions, so I won't have to ovrwrite the one belonging to latest stable release. But let us stay wiht version 5.1 now.

3)+4) Now I think that we agree that when running a DATA SYNC from 4.1 > 4.0 the table structure must be created in advance, as 4.0 does not understand the 'create table' statement from 4.1.

5) “and all swedish chars got messed up in the localhost copy” Did the Swedish characters become two-byte sequences? If yes It very much looks like data have been UTF-8 encoded when reading from 4.1. What is the default character set for the server and the database? (SQLyog will show you from tools .. show .. variables). It looks like database (and server) has utf8 as default, but tables are created explicitly as latin1 with the create statement. SJA queries the character set for the database and use this for 'set names'. You may simply hardcode the tunnelling file to 'set name= latin1;' if this is the case then if all characters can be represented in latin1! (Swedish can and as I said you can have more tunnelling files with different names)

6) I was only talking about 'ordinary' export and the Backup 'powertool'. SJA datasync does not create a SQL-file.

7) “What happens if it looses the connection in the middle of a sync?” Then the sync stops 'half done' , and you'll have to start all over again! simply! But will of course be faster 2nd time as less work needs to be done.

8) This is quite a serious bug with the display in my opinion then!

[peterlaursen]

Now .. it is still not clear to me! :huh:

1) What MySQL version is your localhost?

2) You also don't answer with which SQLyog version you get this result. SQLyog 5.02 or SQLyog 5.1 beta 5? Or both?

3) You get error with ''DEFAULT CHARSET=latin1' when importing to MySQL 4.1 and not with 4.0. That is the opposite world. Are you sure? Your remark on the use of phpmyadmin (we'll soon ban that word! 😎 ) is the 'other way around'.

4) Are you sync'ing into an existing table or is the table (attempted) created by the SJA at sync time? If the latter is the case, what happens if you create the table before the sync with the STRUCTURE SYNC tool (or by hand)?

And when you get this error:

Quote:

You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near 'DEFAULT CHARSET=latin1' at line 5

.. then the error actually can be just befre that! MySQL is not very 'smart' in neither localising or describing errors! But most likely it is the table definition that is the problem. And if the does not understand the table definition then no table is created, and you get the next error

Note that the SQLyog 5.1 (from BETA 5) export tool encodes as UTF-8 with an ordinary export from MySQL 4.1 ++. With the Backup 'powertool' you can choose not to. MySQL 4.0 does not support the utf8 character set. I don't know how this will be with SJA sync in 5.1 FINAL but I don't think there is any change yet here (and the tunneler of BETA 5 is also identical to that of BETA 4, I think)

You can always edit an SQL-file in an editor! Even 'search and replace' UTF-8 encoded special characters with single byte representation.

And the TAG files have nothing to do with neither SJA SYNC nor IMPORT. They are only used by 'autocomplete'.

[peterlaursen]

Quote:

It feels kinda dangerous to be using a BETA-version on a Live important database, is there any risk of data loss?

There ALWAYS is. That is why you need to have a backup plan. Read the standard terms of any software contract. No liability for 'consequental damage' etc … But betas are of course more risky.

Could you explain more in detail (we must get to the very bottom of all this!):

1) With what program versions (SQLyog and MySQL) did you have errors and with which versions did you not ?

2) Which character set is used for the database having Swedish data? (did you notice the utf-8 encoding of backups with SQLyog version 5.1 beta5?)

3) Do you use tunneling for some of the operations?

[peterlaursen]

@Nick.

In another thread I wrote:

Quote:

I you happen to live somewhere in the world where your Windows localisation is not 'western' – (that is correponding to MySQL latin1) – then

1) create this table (with MySQL 4.1 or higher):

Code:

CREATE TABLE tt (id bigint, utftext CHAR(20) CHARACTER SET utf8, ucstext CHAR(20) CHARACTER SET ucs2, latintext CHAR(20) CHARACTER SET latin1);

(replace 'latin1' in the last column with a charset that makes sense with your localisation – and @Nick that is latin5 in your case!)

2) enter some (10-20) rows of data using your national characters. Also enter table and column comments using your national characters

3) Export the table (using the utf8-option) and attach the exported file here with a screenshot of how it should display!

Could I ask you to do so, in return for the program? 🙂

And still I would like to see some similar latin2, latin7, some cyrillic and arabic thing etc. as well!

[peterlaursen]

1) favorites gone … I don't have an idea .. sounds strange in my opinion.

Did you uninstall the program? Then maybe favorites are deleted – though in my opinion they ABSOLUTELY should not! Or did you just copy/move the installation folder?

Don't you have some kind of backup?

2) “I wanna store the favorites on E:, the encrypted disk, not Documents and settings.”

I don't think you can exactly like this. After all favorites are 'application data'. But your favorites need not be te SQL-files themselves – they may be links to files as well (and HTTP-links are planned!). So you can have the sql-files on E: and the favorites need only be links to the real files. Also with WinXP Proffessional you could encrypt the 'application data' folder itself with the encryption that is built in the NTFS file system.

[peterlaursen]

Well actually we are not quite clear here:

The Eula says: http://webyog.com/sqlyogmulti_eula.html

And the FAQ http://www.webyog.com/faq/30_38_en.html

Now in most situations each user has his own computer to work with, and it would then be the same. But it is not always the case. In some environments people are 'moving around' their office and not linked to a specific machine. Here in Denmark it actually is a management 'trend' right now, that employees should NOT have their own desk, computer, but instead move to the place most fit for a certain type of work. It also is supposed to improve the dynamics of an organisation.

I think we should clarify it!

[peterlaursen]

Then let me repeat ..

Quote:

I tried:

1) Running a query (a 'select * from …' running for a few minutes) and killing MySQL Server while query is running. Error message 'Lost connection to server during query' occurs. I can close this popup and close the program easily. This applies to direct connection and SSH-tunnelling as well.

2) Connecting with HTTP-tunnelling and killing the webserver while query is running. HTTP-error '… wrong handle …' occurs. I also can close this popup and close the program.

3) Opening two SQLyog program instances to the same server, running a query from one. While query isrunning I kill user thread used by first program instance from the other instance. No error message occurs, but I can stop the query from red 'X' icon without problems.

4) Tried the same three things with an 'export as SQL'. No problems here either.

First:

A server crash (whether MySQL server or webserver) raises an error.

Second:

I killed the thread used by SQLyog from another client! And I could stop the 'hanging' query from SQLyog.

And let me repeat again:

Quote:

It would still be a help if you could tell how this was reproducable.

If I kill the thread I don't get this error!

The more information you can give the better chances to find the issue! I don't doubt that you experienced this. The screenshot speaks for itself.

[peterlaursen]

I don't understand this

Quote:

Right now, you cannot display data with utf8 charset even though it contains one byte data.

Yes, I can! See attached! There is one ucs2-column and an utf8-column. With ucs2 all characters are two-byte, with utf8 æ,ø and å are double byte.

Also with utf8 a default for the server I can create databases and tables insert and read multibyte data. However I must select 'latin1' at the connections manager.

One-byte utf8 character are the ASCII-subrange only! Positions 128-255 are not mapped in first byte of the utf8 encoding. All other characters take two bytes (all alphabetic writings) three bytes (fear eastern writing) or four bytes (only some rare historical writing styles).

It's rubbish what your are writing here! <_<

[peterlaursen]

Did you specify the new /datadir in the MySQL configuration file?

[peterlaursen]

hmmm …

I agree that UPPERCASE KEYWORDS in SQL generally makes things more readable.

Wasn't it simpler just to have the keywords.db containing KEYWORDS in UPPERCASE?

I am not sure what to think about FuNcTiOnS …. <_< But I would not mind a setting … You can convert keywords in the database to UPPERCASE with the SQLite command line client, just execute:

Code:

Update objects set object_name = UPPER(object_name) where object_type = 1;

.. what I would suggest was done with next release 🙂

Note that if you have added your own KEYWORDS (with LOWERCASES) containing non-ASCII characters, it won't work on those!

[Author]

Posts