[peterlaursen]

I am sorry!

it is the php_mysql (and NOT the php_mysqli) extension that is used by the SQLyog tunnelling file for access to MySQL.

[peterlaursen]

I don't recall ever to have come across the error no. 1 !

Did you upload the tunnelling file and is PHP and php-mysqli extension available ?

Was there no text message associated with the error ?

[peterlaursen]

I think I understand!

See attached picture.

Cursor goes to position 1 when you press and you want it to go to position 2. Right?

I think your request is a result of a not very typical SQL-formatting need. But for the editor of an IDE-programming environment, it is a must.

The editor in SQLyog is optimized for SQL and SQL only. Well … Let Ritesh have a look at it!

[peterlaursen]

Naybe this:

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

would be some help.

You don't have a chance to install SQLyog on some windows machine?

It creates a folder with sample Schemas.

[peterlaursen]

Quote:

This is more of a 2-way sync issue!

I thnik it is a one-way sync issue!.

You have a production DB (not MySQL) that you a intervals copy to a MySQL DB.

Now image that a row is deleted at the source. There is no way for the Migration Tool to delete the corresponding row in MYSQL, except to delete the table from the start.

[peterlaursen]

Cna't you fix dat with the TRIM function ?

I have some data having double end-of-string encoding characters.

I remove it with

Code:

update track set filnavn = trim(trailing RIGHT(filnavn,1) from filnavn);

A TRIM(leading …) at the database having the NULL character should do,

Remember to back up data!

[peterlaursen]

Well I can create users easily with MySQL 5.0.13 and SQLyog Beta 5.

Did you tell the server somehow, that connections are SSL-encrypted ?

[peterlaursen]

proposal.

I the code of SQLyog I believe you build a string for each line that is written to the XML-file. And when each line has been built you do something like

Code:

write(file,string)

that simply could be

Code:

if not string = 'NULL' write(file,string)

then those problematic NULL 's are filtered out and not written.

You can translate from PPL (Peter's Programming Language 😀 ) to C yourself.

[peterlaursen]

thinking about this problems with “orphaned” entries in the MySQL database.

I think it would take another option here (see picture) to choose “delete from target when row is not in source”.

Will probably take a lot of coding to implement. 🙁

[peterlaursen]

Quote:

text colums can for instance not be used in recordsets when I am updating

You can consider to use VARCHAR with MySQL version 5. With MySQL 5 VARCHARS can be about 65000 charcters (as of 255 with previous versions). VARCHARs are more effective with MySQL than TEXTs, due to the different ways that they are stored.

BTW: I don't know the term “recordset” in MS SQL – terminology!

There really has been a lot of issues with the ODBC drivers for MySQL after 3.51.6 (that was real good). however 3.51.6 does not support MySQL greater than version 4.0.

There is a 3.51.12 in beta and a 5.0 in alpha. The 5.0 is recommended for MySQL version 5 (better datatype compability). But it is obvious thht MySQL have big problems with ODBC! And the 5.0 alpha won't install on either of my systems!

However their JDBC driver is excellent. But that won't help you if have applications in Visual Basic or Delphi …

the is a good FTP-mirror with MySQL stuff here:

ftp://sunsite.dk/mirrors/mysql/Downloads/

[peterlaursen]

Quote:

and that was when i found the bug in mysql backup

which bug?

Are you talking about the one we are discussing in this thread, with the the failure to sync, or something else ?

[peterlaursen]

well .. the problem is – as Shawn explained it -that there is this statement

NULL

in the XML-file for each column that does not have a default!

When Shawn deletes those lines from the XML-file it works!

Obviously MySQL 5 does not accept this as it in more respects is more 'strict' in syntax-checking than previous versions.

That should be clear!! If not then read from the beginning 😛

And I still think it is because of poor design of the source database and/or the ODBC-driver! The source must return default=NULL when metatables are queried. How else did it get in the XML-file? There are no such statements in the XML when importing from Access for instance.

But maybe The SQLyog Sync Wizard could “filter out” those statements.

When the first 4.1 beta came out I warned you that there would continue to be non-standard ODBC issues from now till forever. The number of 'propretary' ODBC implemetations with administrative software from the 90'ties are too numerous to mention. I have been working a lot with systems like DATAFLEX and POWERFLEX from that period where ODBC (at best) means 'Only Do Bad Connections' 😀

[peterlaursen]

BTW:

you will also need some way to “clean up” orphaned entries in the MySQL-database (entries that don't exist in the MS SQL database anymore).

…. hmmmm

Any ideas ????

[peterlaursen]

My God —- I've become an expert.

That should be in organic beers and Highland Malts 🙂

[peterlaursen]

Quote:

But I would like to do an automatic sync every 15 minutes

You can do that!

You add a datetime colum to each table for the MS-SQL database.

Then you use the trigger-facility of the SQLyog Migration Tool to update the datetime, every time data are written to MySQL. Also create an “automatic timestamp” with the MS SQL server (that is updated each time some change is done with a row).

Then use the SQLyog Migration -option to only transfer rows having datetimes or timestamps bigger than time of last sync. Note that the trigger-sql and the where-sql must be MS SQL syntax!

This is “incremental import”.

Read the article. There is also a simple “incremental import” example in the SQLyog helpfile!

[Author]

Posts