[peterlaursen]

OK .. server version explains. MySQL 4.0x does not support unicode data with LOAD DATA INFILE. You cannot use utf8 encoded files with that server version.

With MySQL 4.1x and higher there is an option to specify the charset with LOAD data. We will support that from version 5.1 (surrently we asume that the file is utf8 encoded for those server version that support it, and when SQLyog generates a .csv from such MySQL version it is utf8 encoded)

[peterlaursen]

no no .. nothing like 'unpolite'.

But it is just much easir when people give a test case so that we can see ourselves what is happening!

[peterlaursen]

too many words and too little test case!

Please attach a sample CSV file to reproduce with!

” … and Notepad++ for the conversion” Are you sure that this program handles UTF8 correctly?

1) Please avoid that program for the test case. Simply export as CSV from Excel, zip and attach here! Do not convert anything!

2) What kind of 'conversion' are you doing? and how??

3) If you want to convert the CSV-file from ANSI encodong to UTF8 you may use the 'ordinary' notepad (save as .. select UTF8 for the encoding). Also such file you can attach.

So three files please (and please zip):

1) A CSV file directly from Excel

2) File converted to UTF8 with the 'common' Notepad

3) File converted to UTF8 with Notepad++

(and 'convert' means 'save as …' and nothing else!)

[peterlaursen]

did you check version 1.01?

[peterlaursen]

FAQ here tell the same:

http://webyog.com/faq/content/16/66/en/wha…-at-an-isp.html

[peterlaursen]

please detail the 'problems in connecting'! what happens? what does not happen? any error messages?

I suppose you still use HTTP-tunnel? if so:

1) can you connect to the tunneller from a browser?

2) can you connect to MySQL from a simple PHP-script in the same folder (try for instance to build a script executing something like “SHOW DATABASES”)

3) sometimes there are limitations on the webroot folder. There might also be some global webserver directives causing the trouble. If webserver is Apache try creating a subfolder for the tunneller and place an empty .htaccess there. This will turn of such global directives for that folder.

Alternatively try if SSH access is possible. And if 2) is not possible you should definitely ask the support there for help on this. Webserver and PHP misconfigurations happen with freshly configured domains!

[peterlaursen]

Plans were to read from a specific location only.

[peterlaursen]

Next release (6.06) will fix this! Hopefully on first Friday after now! Or beginning of next week!

But I don't think we will make it user specific. probably to program dataMONyog …

[peterlaursen]

There is the FAQ at http://www.webyog.com/faq

This particular issue is adressed here:

http://www.webyog.com/faq/content/34/69/en…han-my-own.html

We are considering if we could integrate the CHM and 'inline popup help messages' and the FAQ.

[peterlaursen]

also:

Are you perfectly sure that it is version 6.05 that throws this error? Actually we believe we fixed it earlier in the 6.0x tree. And we cannot reporduce with 6.05.

If you installed different versions to different locations or if 6.05 install was not successful you may have started another version than what you think you did! Please check the version number from 'about' menu!

[peterlaursen]

Using another webserver also introduces the problem about how that webserver shall connect to MySQL. We will need PHP, ASP(.NET) or JSP then.

MONyog object Model uses the C-API to populate Objects that can be mainpulated JavaScript only. That is simplicity and efficiency!

The only solution I can see (if you absolutely do not want to open an additional port) is to 'pipe' MONyog output to a normal webserver. But that would require MONyog installed on every server .. and that we also wanted to avoid! And I do not know

if it can be done on Windows.

MONyog is 'locked' display the MONyog webpages. It does not accept any other requests. I do not understand how you could fear opening a port for MONyog as long as you dare open one for IIS … 😉

[peterlaursen]

it definitely looks like a user privilege problem. After connection try executing

SHOW GRANTS FOR 'user'@'localhost';

(substitute 'user' with the actual user name – and quotes must be there!

I do not know olm.net, but lots of ISPs let you only manage users form their webbased contol panel application. So maybe SQLyog user management won't work here-

[peterlaursen]

Please check your mailbox!

[peterlaursen]

You could try 'fooling' MONyog by telling it is a LINUX server.

MONyog retrieves the information from the /proc folder (I think it is called) on Linux. This folder does not contain 'real' (disk) files – everything in this system folder is stored in memory actually – but the information is adressed as were it stored in files.

This is not a LINUX concept actually. Also UNIX's do this – and did since first UNIX's saw day of light in the 60'ties. LINUX inherited that concept from UNIX. However there are so many different UNIX branches now (SCO, AIX, HP-UX, Solaris, BSD's and probably more!) and we do not have a monkeyman's chance to test and code for all that.

We would of course appreciate a note if somebody observes that it works on other *nix. Of the many UNIX's I think that FreeBSD and Solaris are most important/most MySQL relevant.

[peterlaursen]

1) please answer: does other SQLyog functionalities seem to work OK?

2) the export tools creates a new connection. Are you able to create a new (identical) connection using Ctrl+N from GUI?

3) you are sure that you have write privileges where you create the file? is not only a 'stub' of the file created?

[Author]

Posts