[peterlaursen]

I understand you can run it interactively from a console, but not from CRON. true?

If so it is a file system or privilege issue!

First understand that the “session xml file” is not the jobfile. They are two different files (both in XML format). The session XML file is used internally.

Did you try the full syntax like:

Code:

./sja “full path to jobfile.xml” s”full path to sessionfile.xml” l”full path to logfile.txt”

note the use of doublequotes and the s-parameter to specify the session file path. Specify a path where the user executing the corbjob has read and write privileges.

[peterlaursen]

You caan copy (select with the mouse and press CTRL C) next past into any text editor or word processor.

We do not support direct printing now.

What is it exactly to “copy the structure to Excel”. Please explain!!

You could consider installing MS Query (an optional MS-Office component). It give a graphical UI for import of data and structure into Excel.

[peterlaursen]

“select all”, “unselect all” and SHIFT-CLICK functionality is on the “to do”.

We all agree that with wig resultsets it is required. We will try to give attention to it as soon as possible. I hope in about 1 month!

[peterlaursen]

would you use bind-adress = 127.0.0.1 ??

Please explain more in detail what setup you would consider.

Also try copying the host file in here!

[peterlaursen]

I never managed to get the ODBC driver for Excel to work.

And never heard about anyone who did. 

[peterlaursen]

and I assume that

SELECT `1` FROM …..  (backticks used) returnswhat you expected?

[peterlaursen]

OK .. not shooting .. 🙄

You should understand that this is SERVER behaviour that a CLIENT cannot change.

Your last example misses the point as variables are declared NULL.

Your own example used variables declared NOT NULL.

(and that I missed in the first shot)

Now consider:  if NULL is not allowed, then the server will need some 'rule' to decide what data that were never entered (because incomplete rows were entered) should be.  In 4.0 this is controlled by column defaults, that the server generates.  In 5.0 it is controlled by the (global and connection) sql_modes.  A 'one to one' copy of NOT NULL variables from 5.0 to 4.0 cannot be established.  4.0 adds a default '0' or DEFAULT for NOT NULL variables.  5.x need not this because it has sql_modes.

Now try copy from one 5.x server to another and it does not happen.  

What illustrates that this is a server issue/behaviour – not a SQLyog issue.

[peterlaursen]

I I executed on 4.0.26

Code:

CREATE TABLE `ora_sprache` (
`ora_sprache_sprachnr` int(10) NOT NULL,
`ora_sprache_beznr` int(10) NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1

it becomes

Code:

CREATE TABLE `ora_sprache` (
`ora_sprache_sprachnr` int(10) NOT NULL default '0',
`ora_sprache_beznr` int(10) NOT NULL default '0'
) TYPE=MyISAM

It is not because your version is old.  This is how MySQL 4.0 creates numericals defined as NOT NULL.  Simply!

Not a SQLyog issue!!!

But not realy a MySQL issue either.  Also on MySQL 5.x data become '0' in most sql_modes.  

You can put it that way that due to sql_modes MySQL 5.x does not need to rewrite

the create statement for NOT NULL colums! Also string variables defined NOT NULL become like “`ora_sprache_sprachnr` char(10) NOT NULL default '' ” (default )

What would you expect with NOT NULL variables if sql_modes are not available on the server side and if a column is defined NOT NULL. Then entering data would raise an error unless all columns were entered with every single INSERT.

[peterlaursen]

1)

the CREATE TABLE statement on 4.1 and higher has an ENGINE and DEFAULT CHARSET specification that MySQL 4.0 and 3.23 does not understand.  So a dump from 4.1 and higher cannot be imported on 4.0 and lower

You will need to delete/comment this string: “ENGINE=InnoDB DEFAULT CHARSET=latin1”

We could enclose in conditional coments like “/*40101 ENGINE=InnoDB DEFAULT CHARSET=latin1*/”

and this very moment I cannot tell why we do not!

2)

“It's the same with 5.27. I even cant remove this with the Alter Table Function: I remove the “0” under “Default”, click “Alter”, window closes – but no change.

But this behaviour should be no problem I think. I would prefer a “1:1″ Copy of the database, though…”

Please follow my procedure.  Create the table from commandline/SQLyog SQL pane, and next execute “show create table”.  Does the SERVER create that default?  Nothing like it is reproducable here!  Do not shoot the piano player (SQLyog) if you really should shoot the bartender (MySQL)!

You are right that a export/import, a copy or a sync all should create a 'one to one copy'.  And it normally does!

3)

“At this point this is no option at is (= as it is ?) a special version of mysql”.  Yes at that time ISP's had the bad habit of 'patching' MySQL.  Now the code has been too complicated.  

And thanks for that, because most of what they did was a mess!

NOTE:

we need a step by step 'reproducable test case'.

[peterlaursen]

Please try to execute (from any client)

Code:

create table `xxx`.`t1` ( `f1` bigint , `f2` int , `f3` tinyint )

on the 4.0.16 server.  What becomes the CREATE STATEMENT for the table?

If I create this table on MySQL 5.0.37 and 'copy to other host' to a 4.0.26 server the create statement becomes on the 4.0 server

Code:

CREATE TABLE `tab1` (
`f1` bigint(20) default NULL,
`f2` int(11) default NULL,
`f3` tinyint(4) default NULL
) TYPE=

I would say that this (default becoming '0') looks like a server issue with a very old server version!

But please try to repeat the above and report.

[peterlaursen]

Code:

I tried backup/restore: not working.

this is not usable information!! To solve issues we need to know what happens, not what does not happen.

The issue probably is that the CREATE STATEMENT for a table is different between 4.0 and 5.x.  You will need to edit the SQL file!

Code:

the new copy has a “default 0” added to every “INT” and “TINYINT”…
Even after I tried to synchronize the structure with “Structure Synchronization Tool” this stays the same.

Lets see what happens.  probably the server inserts this default om some versions!

Code:

to MySQL 4.0.16

🙁   Upgrade!! at least to 4.0.26 or 4.0.27

[peterlaursen]

Start reading the help file on HTTP-tunnel (in the paragraph 'getting started').

Also read this article:

http://webyog.com/en/whitepapers/HTTP_Tunn…hoo_Hosting.pdf

.. for a more detailed explanation.

[peterlaursen]

OK .. thanks for your feedback!

[peterlaursen]

“This worked fine in 5.25.”  

It is not reproducable here with 5.27 or 6.0 beta.

Can you attach a small dump to reproduce with?

BTW: I am moving your post to the “SQLyog” category

[peterlaursen]

First ensure that the data are STORED correctly on the server.

Export a table or database (as utf8 – use SQLyog or mysqldump as you like) and open in Notepad.

Check every non-ASCII/non-English character.

We have seen before that people has implemented a 'workaround' (encoding/decoding in the client) for data not really being stored as unicode.  That we cannot replicate.  But once data are correctly stored we should also display/save/edit them correctly.

[Author]

Posts