[peterlaursen]

1)

Read about numerical types here:

http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html

A decimal is defined with two parameters – if only one is used then MySQL assumes theat the last one is = (zero). A decimal(6) >> decimal(6,0), that is 123456,79 is rounded to 123457. With a decimal(6,1) 123456,79 is rounded to 123456,8. But it would be more normal to use a real or double type. Decimals and floats are for special purposes- real and doubles are the 'common' non-integer types to use with MySQL. You know how to map types with the import proces? Howver for 'precison math' with monetary data in particular, you may stick to DECIMAL. You give in the parameters in the 'length' column. See attached.

2)

using decimals also could to some extend explain the speed issue (they are known to be slow since they are stored as strings before mySQL 5.03). But I simply think this is primarly a matter of tuning MySQL. There are dozens of parameters to tune with, depending on table/engine type and more. How did you decide the buffer sizes in your my.ini? You might get MySQL Administrator and play a little with the various buffers. Also try using the 'my-huge.ini' or the 'my-large.ini'template

Also is it a debug MySQL server that you are running? More info about the server is needed. Where is it running? How do you connect?

3)

To speed up things consider if you can use the FILTERING and SQL_WHERE options to do an incremental import (not to import data that have been imported allready). Refer to:

http://www.webyog.com/faq/14_79_en.html

http://www.databasejournal.com/features/my…p/10897_3550146

[peterlaursen]

there are lots of ways to do such thing allready.

An example:

1) Write a jobfile for ODBC/Migration using where: “where id > dummy” //idea is that 'dummy' shall be replaced

2) Run a PHP script, finding what 'dummy' really should be by querying MySQL. Read the 'dummy'-jobfile from script; make a copy of the XML replacing 'dummy' with that (simple string handling). Execute SJA from the script with the 'replaced' jobfile as parameter.

SQLyog and SJA does not at all relate to PHP or any other server side script. There are no plans for the foreseeable future to change that. SQLyog is based on C, not PHP. Also I believe that the needs of different people would differ anyway. The exact solution that you need nobody else will need exactly like that, I believe. But you can easily do it yourself.

BTW: Your link does not show anything relevant here! (pop-up blocked!)

[peterlaursen]

@Fernando.

We can't se files on your 'localhost' ! 😀

Paste it in instead, so we can see it.

You can generate the jobfile dynamically from a script and then execute it with SJas the last step. You also need not update the ODBC source. And SJA has nothing to do with PHP or ASP – is a compiled binary that runs alone. But I think you will have to explain better.

[peterlaursen]

Links:

http://webyog.com/faq/31_71_en.html

http://webyog.com/faq/15_47_en.html

[peterlaursen]

I don't know .. but actually I experienced the same with quite a lot of programs!

[peterlaursen]

Also Spanish ñ display as cyrillic

(the glyph c represents the 's' sound in cyrillic writing)

And what is this button …

[peterlaursen]

Or maybe rather like the way I have configured my Opera browser.

As of now when lots of connections are open – hidden behind one another – and can be a little tedious t find the one you are after … minimizing until the right one shows up. Here it pops to the foreground with a single mouse-click.

And/or a drop-down somewhere in the menu where to select.

Just SOME WAY to find the connection you are after easy!

[peterlaursen]

Also 'umlaut' characters display as cyrillic in editor like Danish characters.

[peterlaursen]

similar HTTP-WRITE problems with 'umlaut' (german/swedish (and more))characters ä,ö,ü,ë . Like Danish letters its is only LOWERCASES that causes trouble.

A consideration:

But since it READS all sorts of characters correctly it must read and treat the webserver reponse to the GET request (or whatever request type is used). But how to 'adjust' the charset between server and client 'the other way around' – when WRITING?

I don't think this is related to MySQL or 'SET NAMES'. It is a HTTP-server / HTTP-client(and that is HTTP-implementation in SQLyog) -communication issue.

BTW: the charset info that my local Apache sends on a GET request is

Code:

Accept-Charset: windows-1252, utf-8, utf-16, iso-8859-1;q=0.6, *;q=0.1

so it should surely be able to write all those characters correctly if it applies to WRITE too!

[peterlaursen]

to explain the editor issue:

I can use Danish characters in CREATE TABLE and ALTER TABLE and they show correctly in Object Browser. When I doubble-click them into editor the become cyrillic. It also haappens when I type it. Like that on onw Windows machine. On another machine that is dual boot Windows/Linux it happens like that on Linux/Wine, not on Windows.

It is a PURE display thing. I can use those cyrillic names in queries and they return what they should (Danish) in RESULT pane.

[peterlaursen]

@ritesh:

let me repeat:

There are two issues with national characters:

1) The WRITE problem with HTTP is also in SQLyog 4.1. It is identical or almost identical as of now.

2) The display problem with the editor was introduced with 4.2. But editor is also new code (multitabbed + delimiter).

[peterlaursen]

And problem is the same with sja.exe and SQLyogEnt.exe.

A DATA-sync with HTTP raises the same error.

And now this (attached) is funny. I can insert a lot of Danish words with 'ø' – except the last one. The error message is the same i get if I try to insert 'øø'. But most often it is the 'Syntax' error.

@ritesh: a problem with your 'home-made' HTTP-implementation ?? 😛 I do believe it must be some protocol issue.

[peterlaursen]

All explained!

Set NAMES=latin1;

(equal to)

Set character_set_connection=latin1;

Set character_set_results=latin1;

Set character_set_client=latin1;

… are supported from MySQL4.1

(NB: edited)

Neither is supported with MySQL 4.0

But it also does not have any effect to edit the tunnelling file when running MySQL 5.0.

[peterlaursen]

I don't think this

Quote:

I think the command sets the character set and collation for the current connection:

http://dev.mysql.com/doc/refman/5.0/en/cha…connection.html

is correct. All 'collation'-talk is irrelevant to MySQL 4.0.x

I do not understand why the SET NAMES returns a Server Error from SQLyog if it works from PHP.

[peterlaursen]

Another observation ….

If I enter strings like 'øøø' and 'øøøøøøøøø' with direct connection, I get the data returned correctly (that is not transformed to an ASCII-sequence) when reading them from a HTTP-tunnel. So it is a WRITE-problem only – not a READ-problem.

[Author]

Posts