[peterlaursen]

Quote:

I still have no sja.log though.

I think our replys were crossing! No you have not because you are not using SJA DATA SYNC but SQLYOG DATA COPY!

[peterlaursen]

There were quite a lot of quoting errors in what you posted.

However after correcting this and importing I get this:

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 ''Om avbokning sker efter avtalad tid uteˆ[ˆ]™ÚY�9H

LÜ‹‰Ë

(0 ms taken)

It is the same issue as here:

http://www.webyog.com/forums/index.php?showtopic=1915

And that explains that copy fails too, I believe. I have no problems with direct connection.

I know that this is very high priority right now. Ritesh is working intensely on that problem.

Can you tell what is the PHP-version(s) involved in this copy?

[peterlaursen]

Quote:

Where is the log? I searched in the program dir but didn't find anything.

File is called sja.log and is in installation folder. It is created first time you start SJA and should at least read like :”Job started at Wed Mar 15 22:14:52 2006″.

Well maybe the building of tag-files could gives the impression of 'hanging' on some systems. Though I believe Ritesh said that this is done in a seperate thread.

Quote:

My localhost server had username root with no password, but that shouldnt be a problem either?

No problem! Do you connect with HTTP to localhost too?

Hold it .. Hold it

I thought you were talking about the DATA SYNC 'powertool'. But I now understand that you use 'copy to other host' (that is not a sync tool in my opinion). This does not involve the SJA and no sja.log is created. There is a sqlyog.err for the SQLyog/Ent).exe instead.

[peterlaursen]

It works fine here now with BETA3 and your data.

Get BETA3 from the same link as BETA2 .. webpage not updated yet.

(http://www.webyog.com/forums/index.php?showtopic=1943&view=getnewpost)

[peterlaursen]

Confirmed fixed with BETA 3! 🙂

[peterlaursen]

well .. there is a problem with one table.

Is it correctly understood that NO DATA at all come through for that table?

Any error messages in the log?

Are you PERFECTLY sure that the structure on the two hoses are 110 % identical ?

Could you post the 'crate statement' for that table on both host?

It simply looks as if a error is raised when trying to sync that table. Now, if you chose not to 'exit on error' the sync tool proceeds to next table.

[peterlaursen]

1) I cannot reproduce the hang.

I tested with various MySQL servers – including two 4.0.26's. I connect to both without problems with HTTP and direct connection as well.

2) Now the sync issue.

Quote:

Not all table data came along to the ISP. This is a VERY serious problem, since I need to be sure that my data gets transfered correctly.

Of course it is! But you will have to provide more details. Also please read

http://www.webyog.com/articles/Using_SQLyo…L_Databases.pdf and see if it could give you any ideas.

Any error messages in the log? Do you sync with a Primary Key?

[peterlaursen]

Quote:

By the way… Maybe you should change the text in here to reflect that it's actually Beta 3,

The file on the server is a few minutes old only. Probably Ritesh will update the information in the Forums soon!

I'll check your issue!

[peterlaursen]

@ritesh

would you mind explain a little? I would like to understand too!

[peterlaursen]

Now …

when starting the server MySQL 4.0 with cp1251 as default for the server, the exported file holds the HEX value of each (cyrillic) character and not just '?' (char(63)).

But this is not the case with MySQL 5.0. Correct HEX-values are not exported even with cp1251 as MySQL 5.0 server default on my system. All cyrillic are char(63) when exported, but they display in datapane as accented latins when server default is cp1251 (because that are the glyphs that those char-numbers are displayed with on a ANSI-Western system). If server default is latin1 they display AND export as char(63).

Now why this difference of MySQL 4.0 and later?? Does SET NAMES have effect on batch jobs?

[peterlaursen]

Quote:

@chrono: What does the query

CODE

show variables like '%character%'

return?

that was a point!

@chrono: this database shall be the last 'USE'd when you query show variables like '%character%'

@chrono: and did you ever tell what was the MySQL version?

now lets say it returns cp1251 for the database and something else for the server! Then as SQLyog SETs NAMES with the server charset then it does not communicate correctly with the database. That also applies with MySQL <= 4.0 as SET NAMES does not work here and therefore is not sent at all. Now note what chrono wrote at the start

Quote:

the table was created with DEFAULT CHARSET=cp1251.

Well if cp1251 was default for the server, than there would be no need to create the table or database) with that charset

@ritesh: that was your point I guess? Actually if would be pretty simple to SET NAMES as database every time SQLyog sends a 'use ..' statement. However if people write SQL themselves like 'select … from mydb.mytable …' it is more complicated – probably not possible. Not needed either I think. When people are working from the SQL-pane, they should know what SQL to use!

[peterlaursen]

No this is not supported yet! In this article http://www.webyog.com/articles/Using_SQLyo…L_Databases.pdf I actually requested it!

But you may be able to use the option of the data sync tool to sync the rows of (a) table(s) that are used for defining the VIEW only! But the sync tool will always sync complete rows!

[peterlaursen]

What guys think?! We rarely do ..no time for that .. most of the time we just work! 😀

Jokes apart, please read: http://www.webyog.com/faq/33_20_en.html

(this may be changed soon as we might decide to do this “As a consequense localisation to ALL languages will be possible. This applies to data management as well as program's appearance.” in two steps: first Data Management, next Program's Appearance. We will detail when 5.1 final is released)

What you request is covered by “Improved management of relationships/Foreign Keys.” It is such graphical diagramming tool that we are thinking of.

[peterlaursen]

just a small observation:

HTML-export generates like:

Code:

01

Мужские

Note it does not use ISO 8859 '&aring' for 'е' but simply hex E5 (decimal 229) etc.

However Firefox is smart enough to realize that this must be cyrillic!

Even when there is no charset information in the header of the HTML-file

IE and Opera does not! Unless I force them to use windows-1251 encoding.

(@ritesh: shouldn't there be a charset=”windows-1251″ declaration in HTML-file when data are cp1251?).

I think a as-fast-as-possible implementation of UTF-8 is the only real solution to all these problems.

In another thread I linked to a few libraries!

[peterlaursen]

Of course I forgot one thing. When working with your data I must SET NAMES accordingly. I did that now. See attached. Now your cyrillc charcters display as various accented latin-based characters. But that is of course due to the ANSI localization (mapping of characters 128-255) on my Windows installation.

Export as HTML and CSV yields the same.

However export as .SQL still produces '?'

Code:

/*Data for the table `sizes` */

insert into `sizes` (`size_id`,`size`) values (01,'???????');
insert into `sizes` (`size_id`,`size`) values (02,'???????');
insert into `sizes` (`size_id`,`size`) values (03,'???????');
insert into `sizes` (`size_id`,`size`) values (04,'??????? (????)');
insert into `sizes` (`size_id`,`size`) values (05,'?????????');
insert into `sizes` (`size_id`,`size`) values (06,'????????');
insert into `sizes` (`size_id`,`size`) values (07,'??????????');
insert into `sizes` (`size_id`,`size`) values (08,'?????????');
insert into `sizes` (`size_id`,`size`) values (09,'?????????');
insert into `sizes` (`size_id`,`size`) values (10,'????????????');

The same thing happens with Backup 'powertool'.

1)

Now .. it looks like both backup tools fail to map non-ASCII characters with cp1251 charset. Now the developers will have to consider if same thing happens with other charsets.

2)

SET NAMES should be done on a database (or better table or better column) basis when a DB has another charset than the server default – not only on a server basis

[Author]

Posts