[Bill Nguyen]

peterlaursen wrote on Aug 7 2009, 08:53 PM:

We have this FAQ:

http://www.webyog.com/faq/content/23/36/en…t-connect-.html

Thanks Peter!

I have admin rights on this Windows 2008 Enterprise server (housing Sharepoint MOSS 2007).

I was able to connect using HTTP-tunneling, but still wonder about the performance of HTTP-tunneling vs direct connect.

Bill

[Bill Nguyen]

peterlaursen wrote on Jun 26 2009, 08:55 PM:

It is the MySQL user details that are wrong. What your MySQL user name and password is I cannot possible tell.

Peter;

You are correct, again!

I put my domain name in the box instead of “localhost” and that has caused all the troubles! I tried localhost (default, supplied any userid & password I created in mySQL and it worked!

Íll save the info, in case my PC crashes again!

Thanks

Bill

[Bill Nguyen]

peterlaursen wrote on Jun 26 2009, 06:30 PM:

It is impossible for us to know what hostname to use for connecting from the tunneller to the MySQL server with specific hosting (if it is not 'localhost').

Dear Peter;

The mysql server host name is vanhocvietnam.org. That's what I entered in both SQL & HTTP tabs. (http://vanhocvietnam.org/SQLyogTunnel.php)

The problem is that what to put in the field “UserName” and “Password” in both SQL tab and Advanced – Use Credentials portion of HTTP tab.

I enter the primary userID and password. This is the account I can access CPanal, mySQL control panel, and PHPmyAdmin.

Still got access denied for the account in question.

Hope this help clarify the issue.

thanks

Bill

[Bill Nguyen]

Dear Peter;

This is what I did:

Copy the table to another database (for converting)

Modified your query to reflect table name chang as below:

alter table -`vanhocvi_migration`.`jos_magazine_users` change `full_bio` `full_bio` longtext character set latin1 NOT NULL;

alter table -`vanhocvi_migration`.`jos_magazine_users` change `full_bio` `full_bio` longblob NOT NULL;

alter table -`vanhocvi_migration`.`jos_magazine_users` change `full_bio` `full_bio` longtext character set utf8 collate utf8_unicode_ci NOT NULL;

Ran the query

Got error msg as follow:

Error Code : 1064

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 '-`vanhocvi_migration`.`jos_magazine_users` change `full_bio` `full_bio` longtext' at line 1

(359 ms taken)

Removed hyphens from queries as follow:

alter table `vanhocvi_migration`.`jos_magazine_users` change `full_bio` `full_bio` longtext character set latin1 NOT NULL;

alter table `vanhocvi_migration`.`jos_magazine_users` change `full_bio` `full_bio` longblob NOT NULL;

alter table `vanhocvi_migration`.`jos_magazine_users` change `full_bio` `full_bio` longtext character set utf8 collate utf8_unicode_ci NOT NULL;

Ran again, I went thru this time.

Check data in full_bio, no change:

Nguyễn Quí Đức laÌ€ tác giả cuốn Where The Ashes Are (Addison-Wesley), Ä‘ôÌ€ng chủ biên hai tuyển tâÌ£p Vietnam: A Traveler’s Literary Companion (Whereabouts Press) vaÌ€ Once Upon A Dream (Andrew & McMeel), vaÌ€ diÌ£ch cuốn Behind the Red Mist (HôÌ€ Anh Thái), vaÌ€ The Time Tree (Hữu Thỉnh), Giải Chung kết DiÌ£ch thuâÌ£t năm 2003 của HiêÌ£p hôÌ£i Phê BiÌ€nh Văn HoÌ£c tiểu bang California. Anh cũng viết vaÌ€ diÌ£ch nhiêÌ€u truyêÌ£n ngắn, ̣đăng tải trên nhiêÌ€u taÌ£p chí vaÌ€ tuyển tâÌ£p văn hoÌ£c. Anh viết báo vaÌ€ laÌ€m cho nhiêÌ€u Ä‘aÌ€i phát thanh/truyêÌ€n hiÌ€nh quốc tế tÆ°Ì€ hÆ¡n 20 năm qua.

I do not know what you did, but apparently I did NOT do it right!

Thanks

Bill

[Bill Nguyen]

peterlaursen wrote on Sep 20 2008, 09:55 PM:

you will have to zip it or rename to .txt!

We do no allow for .sql files. This is in order to protect users to accidentially execute it! Same applies to .exe. Please .jpg, .gif, .png, .txt and .zip only!

Sorry Peter! I thought it was about the file size! Here's the zipped smalltable.sql.

Thanks

Bill

[Bill Nguyen]

Dear Peter;

Please review the smallTable.SQL attachment. It's only 3Kb, so I guess I don't need to zip it.

Thanks a million

Bill

[Bill Nguyen]

Dear Peter;

Thanks for your prompt response! In reading the suggested article, I think I may need to do the followings.

So basically what you need to do is to perform changes in two operations like:

latin1 varchar >> varbinary (or BLO:cool: >> utf8 varchar (and similar for char and TEXT types).

This you will have to do on every existing string column in every table.

You may want also change the default charset for every table and for the databases(s), so that new tables and columns will be created as utf8 (in case of an application upgrade for instance).

As an example, the 2 paragraph below show the actual display (in table column) adn the way it should display (on a webpage):

1. As stored in the table:

Bắt đầu sáng tác năm 1989, Ngô Tự Lập là m thơ, viết truyện ngắn và tiểu luận. Anh cũng là một dịch giả tiếng Nga, tiếng Pháp và tiếng Anh. Hội viên Hội nhà văn Việt Nam và Hội nhà văn Hà Nội, anh đã xuất bản trên 20 tác phẩm sáng tác, dịch thuật và biên soạn.

2. As viewed on a webpage:

Bắt đầu sáng tác năm 1989, Ngô Tự Lập làm thơ, viết truyện ngắn và tiểu luận. Anh cũng là một dịch giả tiếng Nga, tiếng Pháp và tiếng Anh. Hội viên Hội nhà văn Việt Nam và Hội nhà văn Hà Nội, anh đã xuất bản trên 20 tác phẩm sáng tác, dịch thuật và biên soạn.

or in this link:

http://damau.org/index.php?option=com_maga…39&Itemid=1

I only need to convert the data into proper format and send it to some place, fixing the existing database is not necessary. Please tell me the steps I need to take to get this straightened out.

Thanks again

Bill

[Bill Nguyen]

peterlaursen wrote on Jun 8 2007, 11:17 AM:

@don

He is storing some web based encoding as binary data, I believe!  His has a client program of some kind that does the encoding/decoding.

Peter;

The “binary” part is probably true for the article body. However, for article titles such as Nhà ăn lúc chiều tối và má»™t hồ bÆ¡i trong mÆ°a, are they also in binary?

You're correct in “web-based encoding” since we use an HTML editor to upload and maintain articles.

If I can send text directly (via sql) using SQLyog, what charset do I need to use?

Thanks

Bill

[Bill Nguyen]

1) It it Vietnamese?

Yes, it's Vietnamese

2) MySQL version?

Server version: 5.0.27-standard-log

3) If you ever tried version 5.x could you read it correctly with this one?

I got same problem with 5.x

4) What program would you normally use to view the data?

SQLyog and phpMyAdmin

5) Please connect to the database and execute “SHOW VARIABLES LIKE '%character%';” and paste the result here

character set client utf8

(Global value) latin1

character set connection utf8

(Global value) latin1

character set database latin1

character set filesystem binary

character set results utf8

(Global value) latin1

character set server latin1

character set system utf8

character sets dir /usr/share/mysql/charsets/

collation connection utf8_unicode_ci

(Global value) latin1_swedish_ci

collation database latin1_swedish_ci

collation server latin1_swedish_ci

6) Please create a small table with such characters, export(dump) it using utf8 encoding (the SQLyog 'export' does), zip and attach here.

jos_content_dump.zip

Thanks

Bill

[Bill Nguyen]

sasa wrote on Oct 4 2006, 07:08 AM:

UPDATE: Oh boy, never mind! I found it.

Sasa;

Can you please elaborate?

I'm getting data in ASCII format (from original Unicode text), causing the text unreadable.

Is there a way to convert it back into unicode while working with SQLyog?

Thanks

Bill

[Bill Nguyen]

peterlaursen wrote on Oct 5 2006, 05:25 PM:

Open that SQL file in an editor and 'search and replace' 'DEFAULT CHARSET=latin1' with '' (empty string).

remove 'SET NAMES .. ' statements a similar way. Replace ENGINE (if it is there) with TYPE (have a copy of course!). We will get rid of all those syntax'es that do not work with 4.0. Create a backup with SQLyog of a small table a see what it should look like!

How big is this file?

Peter;

My web host finally repaired the database and the error went away. I was able to execute the batch import to another database without incident.

Thanks

Bill

[Bill Nguyen]

Quote:

But please try SQLyog 5.2 beta5. Before that there was a problem with /*! ..*/ style comments ('conditional comments') Good chances that this is the issue!

I installed 5.2 beta5 (Enterprise version) and got the same error:

Error occured at:2006-10-05 09:16:08

Error Code: 1064 – 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 7

This doesn't make sense to me since I'm connecting directly to the host database (mySQL 4.0.27) and restored the same sql batch created by phpmyAdmin 2.7, how come it didn't work?

Please help!

Thanks

Bill

[Bill Nguyen]

peterlaursen wrote on Oct 5 2006, 01:21 PM:

You arw exporting from a MySQL 3.23 or 4.0 server and importing to 4.1 or higher. That won't work! SQL is different.

You have two option:

1) edit the SQL-file to fit the syntax of of the server version you import to.

2) I think that phpMyAdmin has an option to generate 'compatible backups'. You can try. But be perfectly sure that the charset on boths servers are the same!

MySQL is not really designed to 'work across versions'. We have our problems ourselves to keep STRUCTURE SYNC 'compatible' too for instance!

Peter;

Here's the situation:

my local mySQL server is 5.0

I exported the database from the host (mySQL 4.0) using phpmyAdmin. Then I use SQLyog “Import batch file” to import the .sql file successfully. I assume that this also converted the database into 5.0.

Can I export the database again in mysql 4.0 format ?

Thanks

Bill

[Bill Nguyen]

The reason for restoring the database:

A table got corrupted and I cannot repair it using SQLyog table diagnostics tool to repair.

HEre's the error message:

#1033 – Incorrect information in file: './damauorg_website/mod_article.frm'

Thanks

Bill

[Bill Nguyen]

peterlaursen wrote on Aug 31 2006, 04:52 PM:

However the Tunnelling technology of SQLyog would allow for that as well. We plan to release this feature as a seperate application in some months.

Well, too bad I have to wait! I always had the feeling that things are not that easy 🙂

In the meantime, any suggestion regarding connection string or ODBC? Even a 3rd party util out there?

Thanks a bunch!

Bill

[Author]

Posts