[peterlaursen]

@ritesh

this

Code:

call `mydb`.`myproc`(parameterlist)

gave me an idea for the future: an ability to dynamically pass parametres to SP's and functions from SJA/Notifications Wizards will really rock the boat!

like

Code:

anyone out there using SP's extensively who could tell what facilities would be useful ?

[peterlaursen]

Quote:

Better data structure implementation in Table/Data tab.

It that the columns defaults issues with CURRENT_TIMESTAMP, SESSION_USER and char/varchar/text NULL etc that will be solved here ?

[peterlaursen]

fine …

but I think you should release 5.01 ASAP if it is perfectly sure that the lexer-bug is fixed. And I think it is. Even if the docs and minor issues are not quite finished yet (there must then be a 5.02 i 1-2 weeks time – though I know you hate those 'small releases'!) . But the lexer bug is a potential data destroying bug, and that is serious!

Or at least you could make the 5.01 BETA publically available.

[peterlaursen]

yes – I think you can

1) but I dont want to send an email

>>> then just choose 'run maintenaince query' on the first screen of the notification wizard

2) I would prefer to run a stored procedure

>>> your SQL to execute with the SJA job is then just

Code:

call `mydb`.`myproc`();

or

Code:

call `mydb`.`myproc`(parameterlist)

3) …command on an hourly basis between the hours of 8.am and 8pm 7 days a week

>>> See attached screenshot of Windows Scheduler. It is all available from the 'advanced' settings. Sorry it is in Danish (applies to language as well as time format)

Did I forget something?

[peterlaursen]

You can try this (it has worked before)

1) Convert timestamps to strings (ALTER TABLE …)

2) Do Sync

3) Convert strings back to timestamps.

1) and 3) can be done from jobs running in same batch as the sync job.

Basically a MySQL timestamp is stored internally identically as is a char(14) … like 'yyyymmddmmhhss' or '20051202003145' so the conversion forth and back should be pretty straight.

But of course any application/script that makes use of the timestamp will fail. So in practice I think it would be wise somehow to block access to the database for other apps while the process is running

[peterlaursen]

Well .. situation changed a little ..

I wrote

Quote:

(actully I have 3.23, 4.0, 4.1 and 5.0 installed at the same time).

It is now

Quote:

(actully I have 3.23, 4.0, 4.1, 5.0 and 5.1 installed at the same time).

😀

Actually I can copy tables from 5.1.3 to 4.0.26 as well. It confirms what I wrote at the beginning

Quote:

But to me it looks like the program tests for version() >= 5.0 (where it should be >= 4.1) .

@ Ritesh ???

[peterlaursen]

and ..

[peterlaursen]

Connection successful … 😀

[peterlaursen]

My God – it is the slowest download I ever experienced from a Sun FTP-site!!

Probably quite a lot of people that have found out!

[peterlaursen]

Quote:

Are you saying that if I upgrade my local Version of MySQL to v5.0 then I will be able to copy from MySQL v5.0 to MySQL v4.025 using SQLYOG v5.0…..

Exactly! I can copy tables from 5.0.16 to 4.0.26

Actually you won't have to uninstall MySQL 4.1. They can both be installed. (actully I have 3.23, 4.0, 4.1 and 5.0 installed at the same time). To change between versions you can edit the startup parameters (there are 4 strings to be edited) with “MySQL Administrator” from http://dev.mysql.com and stop and restart the servers.

But 4.1 and 5.0 won't use the same /datadir. So ether you must dump your 4.1-databases and import to 5.0 after the installation. Or if you make a copy of the old /datadir you must run the mysql_fix_privilege_tables.sql script from command-line client before using it with mySQL version 5.

I can guide you if you are totally helpless with this! It is a 2 minute show if you know what you are doing! But anyway backup anything – data and the my.ini file before playing around.

BTW: MySQL 5.0.16 is available from FTP-mirrors such as ftp://sunsite.dk/mirrors/mysql/Downloads/MySQL-5.0/ . http://www.mysql.com still only links to 5.0.15 (probably because all binaries are not finished yet – but the Windows binaries are!)

[peterlaursen]

Quote:

what products are you referring to SQLYog or MySQL???? Not clear.

Sorry! I was copying tables successfully from MySQL 4.1.15 to MySQL 5.0.16 using SQLyog 5.0.

I beleive this is a problems that occurs only when copying from mySQL 4.1 to MySQL 4.0 or earlier. And I believe it is an easily-fixable bug with SQLyog (when it can work with MySQL 5 it should so with 4.1 too)

I did not suggest that your hosting provider should upgrade MySQL. That last post of mine was just some additional info for Ritesh & Co.

However YOU can upgrade from MySQL 4.1 to 5.0 on your local if you can't wait for the fix.

[peterlaursen]

Just tested copy from 4.1 to 5.0 and it works fine.

but the 'default charset …' in the create statement also is identical across these versions.

[peterlaursen]

Quote:

the error – can it be fixed??

I don't have access to the program code (and probably I would not be able to understand it anyway), so wait for Ritesh to show up and give his comment.

But to me it looks like the program tests for version() >= 5.0 (where it should be >= 4.1) . There has been a lot of focus on the new features of MySQL 5.0 – so maybe it simple was forgot that some of the new stuff was also introduced with 4.1.

That is my guess. And if that is it, I believe it should be quite simple to fix.

[peterlaursen]

You are right!

When copying from local 4.1.15 to remote 4.0.26 I get the error message too.

All relevant info should be in the screenshot!

[peterlaursen]

Yes it should be fixed and it works here! See attached.

This is a “Copy Table” from local MySQL 5.0.16 to webhost 4.0.26 (and using HTTP-tunnel actually).

On the source (ver 5.0.16) the create statement goes

Code:

CREATE TABLE `account` (                          
          `AcCode` varchar(3) NOT NULL default '',        
          `AccountName` varchar(40) NOT NULL default '',  
          PRIMARY KEY  (`AcCode`)                        
        ) ENGINE=MyISAM DEFAULT CHARSET=latin1

On the Target (4.0.26) it is after copy

Code:

CREATE TABLE `account` (                          
          `AcCode` char(3) NOT NULL default '',          
          `AccountName` varchar(40) NOT NULL default '',  
          PRIMARY KEY  (`AcCode`)                        
        ) TYPE=MyISAM  

Two questions:

1) I believe that it is this ENGINE=MyISAM DEFAULT CHARSET=latin1 that you must 'strip out' to make it work ? Could you show us EXACTLY the create statement that works and one that does not?

2) You seriously mean that target mySQL version is 4.0.1? This is a very early 4.0 alpha that is NOT recommended for production use!

I'll check with 4.1 too as the source. But I doubt that it matters!

[Author]

Posts