still problems with \ character in PK

[peterlaursen]

Just tested the SJA 4.07 beta1 with my data to see if a char/varchar field containing a Windows' filename can now be use as a PK with SJA. It still can't!

Both servers MySQL 4.0.24 – it is a one-way sync from localhost to my webhost using HTTP-tunnelling

When syncing with another PK (25 charcater varchar containing only hex-numbers and the “-“character like “0003820E-791C-42DC-BC3C-9”) I get this (correct with my settings) result:

Table SrcRows TgtRows Inserted Updated Deleted

========================= ======= ======= ======== ======= =======

`mp3_filer` 38306 38215 152 157 44

When using a complete windows filename (255 character varchar containg “”s) as the PK I get (after a few seconds)

Table SrcRows TgtRows Inserted Updated Deleted

========================= ======= ======= ======== ======= =======

`mp3_filer_copy` 38306 38215 0 0 0

The data of the two tables are totally identical except for the PK-definition! Trying different settings for COLUMNS_ALL and SQLWHERE (and omitting these completely) does not change anyting.

I still have a copy of both sets of data as they were and can give you access to them.

[peterlaursen]

I just repated trying to sync the table between two DB's on my localhost using SJA (just to be sure that it was not involving some mess with my ridiculous webhost!). It won't work either when PK is a Windows' filename. No matter whether HTTP-tunnelling is used or not.

However, if I start with an EMPTY TARGET DATABASE (emptying the “mp3_filer_copy” table), all rows from table “mp3_filer” are synced (inserted). It seems to be same issue as reported here

http://www.webyog.com/forums/index.php?act…st=0&#entry6004

@Ritesh:

If you still have connection details to my test DB on my webhost there is now a table “mp3_filer” containing result of a succesfull sync (not using filname as PK) and another table “mp3_filer_copy” with the data on target before the sync. (Please note the different PK's with the two tables). Some field identifiers are in Danish Language. Hope you can handle that 😉

If use use the field “Filnavn” (means “File Name”) as the PK you will not be able to sync with table “mp3_filer” as the sorce and “mp3_filer_copy” as the target. It gives 0 inserts, 0 updates, 0 deletes.

[peterlaursen]

I can mail you DUMPS of the two tables as well. ZIP-file approx. 5 MB.

[peterlaursen]

Same behaviour with MySQL 5.07

When syncing to a target that is empty, rows are INSERTED as they should

But when target is NOT empty result is (as before)

Table SrcRows TgtRows Inserted Updated Deleted

========================= ======= ======= ======== ======= =======

`mp3_filer_copy` 38306 38215 0 0 0

Total time taken – 16 sec(s)

[Ritesh]

I still have the connection details of your server. I will look into the matter as soon as possible.

[Ritesh]

Is it possible to reduce the set of data to reproduce the error more easily?

[peterlaursen]

honestly I don't know. I will give it a try … wait ½ hour …

[peterlaursen]

Yes it is! Its the same with enclosed ZIP-file. It has 2 .sql-files in it

source.sql has 14 rows – target.sql has 10 rows.

It is a MySQL 5.x dump – to import to earlier versions delete string “DEFAULT CHARSET=latin1” from table definition.

[peterlaursen]

you can create any subset of data from the server yourself with this SQL

Code:

Create table tbl_name select * from mp3_filer where kunstner like 'something';

For instance this reduced dataset was created with

Code:

Create table table_name select * from mp3_filer where kunstner like 'aba%';

[peterlaursen]

Hold it!

I believe it was the wrong files! 10 minutes more!

[peterlaursen]

This one should be better:

there are now 17 rows in source, 14 in target.

Result with SJA:

Table SrcRows TgtRows Inserted Updated Deleted

========================= ======= ======= ======== ======= =======

`testsync2` 17 14 0 0 0

Total time taken – 1 sec(s)

Correct would be: 3 insert, 2 updates, 0 deletes

and still the same with an empty target: rows are inserted correctly.

[peterlaursen]

Just info for those reading here:

This:

http://www.webyog.com/forums/index.php?act…t=ST&f=6&t=1503

and maybe this

http://www.webyog.com/forums/index.php?act…st=0&#entry6004

seem related with this issue. It does not seem to be an issue with SQLyog.

[peterlaursen]

@Ritesh

Maybe this is not a PK-problem, but rather a problem with escapes and wildcards used in conjunction!!

I consider posting this to MySQL bug system, but I'll let you read it first:

********************************************************************************

*******

Another way to reproduce:

STEP ONE: import this dump:

create database if not exists `music`;

USE `music`;

/*Table structure for table `test` */

DROP TABLE if exists `test`;

CREATE TABLE `test` (

`filename` varchar(255) NOT NULL,

`title` varchar(255) default NULL,

`artist` varchar(255) default NULL,

`album` varchar(255) default NULL,

PRIMARY KEY (`filename`)

);

insert into `test` values ('M:\Peters Musik\Abaji\Oriental Voyage\10 Tchai.mp3','Tchai','Abaji','Oriental Voyage');

STEP TWO: queries

Two queries that WORK:

1)

mysql> select title, filename from test where artist = 'abaji';

+

---

+

---

+

| title | filename |

+

---

+

---

+

| Tchai | M:MusicAbajiOriental Voyage10 Tchai.mp3 |

+

---

+

---

+

1 row in set (0.00 sec)

2)

mysql> select title, filename from test where filename like '%\abaji%';

+

---

+

---

+

| title | filename |

+

---

+

---

+

| Tchai | M:MusicAbajiOriental Voyage10 Tchai.mp3 |

+

---

+

---

+

1 row in set (0.00 sec)

Two queries that DON'T WORK:

3)

mysql> select title, filename from test where filename like '%\abaji\%';

Empty set (0.00 sec)

4)

mysql> select title, filename from test where filename like '%abaji\%';

Empty set (0.00 sec)

Please tell me what's wrong with the use of escaping with these two ??

However this one works:

5)

mysql> select title, filename from test where filename like '%\abaji\%';

+

---

+

---

+

| title | filename |

+

---

+

---

+

| Tchai | M:MusicAbajiOriental Voyage10 Tchai.mp3 |

+

---

+

---

+

1 row in set (0.00 sec)

But why is it necessary to escape the % character here ??

The MySQL manual says

“To test for literal instances of a wildcard character, precede the character with the escape character. If you don't specify the ESCAPE character, '' is assumed.”

However this is not how it behaves in this case!! It seems that escape and wildcard charcters don't always behave as they should when used in combination. with these examples here it does not change anything to change the PK. So maybe it's not a problem related to the PK-setup.

Attached: data shown in graphical client (Open Office 2 Base);

[peterlaursen]

I believe now that there is a trivial problem with MySQL's parser where there are two many -characters in a char or varchar field! (some buffer-overrun ??). That takes effect when used with a WHERE and maybe elsewhere ….

In the attached pic only the last query returns correct result! The others return nothing.

[Ritesh]

I guess I will need to call up MySQL AB's support team to discuss on this issue. I have no clue why its behaving like this.

Quote:

data shown in graphical client (Open Office 2 Base);

You can use SQLyog for the same purpose 😮

[peterlaursen]

Quote:

You can use SQLyog for the same purpose

I know! But I don't know if MySQL has some “policy” about exposing third-party clients like SQLyog in their bug-tracking system.

[peterlaursen]

and besides …

Open Office Base supports VIEWs when used with JDBC 😛

[peterlaursen]

/* SOME SUMMARIZING ON THE ISSUE */

/*

SQLyog Enterprise v4.07 BETA 2

Host – 5.0.7-beta-nt-max : Database – test

*********************************************************************

Server version : 5.0.7-beta-nt-max

*/

create database if not exists `test`;

USE `test`;

/*Table structure for table `test` */

drop table if exists `test`;

CREATE TABLE `test` (

`kunstner` varchar(255) NOT NULL,

`albumtitel` varchar(255) default NULL,

`titel` varchar(255) default NULL,

`filnavn` char(255) NOT NULL,

PRIMARY KEY (`filnavn`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

/*Data for the table `test` */

insert into `test` values ('Abaji','Oriental Voyage','maa','M:\Peters Musik\Abaji\Oriental Voyage\11 maa.mp3');

/* Queries that don't work but should – NOTE: no % character at the end*/

select * from test.test where filnavn like '%mp3';

select * from test.test where filnavn like '%\11 maa.mp3';

select * from test.test where filnavn like '%voyage\11 maa.mp3';

/* Queries that work (and should too!) – NOTE: % character at the end */

select * from test.test where filnavn like '%mp3%';

select * from test.test where filnavn like '%\11 maa.mp3%';

/* As we have seen before this works */

select * from test.test where filnavn like '%\Oriental Voyage\%';

/* but why must % character be escaped ? – */

/* this should match string 'Oriental Voyage%' only */

/* None of these work*/

select * from test.test where filnavn like '%\Oriental Voyage\11 maa.mp3%';

select * from test.test where filnavn like '%\oriental voyage\11 maa.mp3%';

/* Pattern with trailing % character broken with example on line 18 */

/* It seems to confirm theory that 'too many' -characters in data raises error*/

/* NOTE: Result the same no matter what column is the PK (or if there are any)! */

[peterlaursen]

My God I am becoming crazy with this!

There might have been some errors with some of my data in some previous examples.

So let's have a fresh start.

However this is now VERY CAREFULLY checked.

And simplifies matters as much as possible I believe.

(example edited a little ½ hour after first posting with a few more examples)

BTW: could it be that LIKE and concat_ws uses part of same algorithms ??

That could explain that SJA is affected!

********************************************************

create database if not exists `test`;

USE `test`;

/*Table structure for table `test` */

drop table if exists `test`;

CREATE TABLE `test` (

`artist` varchar(255) default NULL,

`albumtitle` varchar(255) default NULL,

`title` varchar(255) default NULL,

`filename` char(255) default NULL

);

/*Data for the table `test` */

insert into `test` values ('Abaji','Oriental Voyage','maa','M:\Music\Abaji\Oriental Voyage\11 maa.mp3');

/* Queries that work as expected */

/*1*/ select * from test.test where filename like 'M:%';

/*2*/ select * from test.test where filename like '%mp3';

/*3*/ select * from test.test where filename like '%\11 maa.mp3';

/* Queries that don't work but should */

/* It seems like that 'too many' -characters in data and/or query influences error */

/*4*/ select * from test.test where filename like '%Voyage\11 maa.mp3';

/*5*/ select * from test.test where filename like '%\Oriental Voyage\11 maa.mp3';

/*6*/ select * from test.test where filename like '%\Abaji\Oriental Voyage\11 maa.mp3';

/*7*/ select * from test.test where filename like '%\Oriental Voyage\%';

/* However these two works – but I think they should not! */

/* – 8 should match string 'Oriental Voyage%' since % is the escape sequence of of a literal %-character */

/*8*/ select * from test.test where filename like '%\Oriental Voyage\%';

/*9*/ select * from test.test where filename like 'M:\%';

/* there isn't much logic, since these two don't work – again 'too many' characters ? */

/*10*/ select * from test.test where filename like 'M:\Music\%';

/*11*/ select * from test.test where filename like 'M:\Music\Abaji\Oriental Voyage\%';

/* these don't work either */

/*12*/ select * from test.test where filename like 'M:\%';

/*13*/ select * from test.test where filename like 'M:\Music%';

/*14*/ select * from test.test where filename like 'M:\Music\Abaji\Oriental Voyage\%';

/*15*/ select * from test.test where filename like 'M:\Music\Abaji\Oriental Voyage\11 maa.mp3';

/* this one works here – compare with 15! */

/*16*/ select * from test.test where filename = 'M:\Music\Abaji\Oriental Voyage\11 maa.mp3';

/* NOTE: Result the same with this case no matter what column is the PK (or if there are any PK or indexes at all!) */

/* and inserts, updates and deletes function/malfunction the same way with the same WHERE-clauses */

[peterlaursen]

@ritesh

what do you think of above case (10:54 AM) ?

It should be fairly easily reproducable. I have made a layout so that you can just copy the whole of it into SQL-pane in SQLyog and execute 1st statement, then 2nd statement etc.

The case that you posted at bugs.mysql.com was easily reproducable too, but unfortunately this Victoria doesn't seem to have tested it seriously. I believe that this case should not be rejected the same easy way. What would be best, do yo think:

1) I post it to bugs.mysql.com

2) You post it to bugs.mysql.com

3) You will have it brought to attention of MySQL AB some other way (using your contacts with MySQL ?)

It probably is not the whole truth about this issue. But it should be sufficient to demonstrate that there is a need for some research into the reasons for this.

From your point of view, I think that – if it's is a bug with MySQL that also causes SJA to fail under certain circumstances (what I believe it is) – the issue is important. Some failure with ordinary SQL can be tested with command-line client or some other client, but there is no other tool to test with if SJA fails. And thus users will blame SJA, negatively affecting the reputation of the program – even in cases where it is an issue with the MySQL server. There just is no easy way to prove it!

So what next ?

[Ritesh]

Quote:

You will have it brought to attention of MySQL AB some other way (using your contacts with MySQL ?)

We are Authorised Gold Partners of MySQL AB. I have already started a conversation with MySQL AB developers on this issue and talks are going on. I will reply here once I get a concrete solution to the problem.

[peterlaursen]

fine with me – I won't do any further then unless requested!

[peterlaursen]

We're not alone!

http://bugs.mysql.com/bug.php?id=11583

[Ritesh]

😀

[peterlaursen]

Some variations on the theme (continuation from Jun 26 2005, 10:54 AM)

to me it seems completely impredictable when to use \ and when to use \\ 🙁

/*5 works not */ select from test.test where filename like '%\Oriental Voyage\11 maa.mp3';

/*5a works */ select * from test.test where filename like '%\Oriental Voyage\\11 maa.mp3';

/*5b works not */ select * from test.test where filename like '%\\Oriental Voyage\11 maa.mp3';

/*5c works */ select * from test.test where filename like '%\\Oriental Voyage\\11 maa.mp3';

/*6 works not */ select * from test.test where filename like '%\Abaji\Oriental Voyage\11 maa.mp3';

/*6a works not */ select * from test.test where filename like '%\Abaji\Oriental Voyage\\11 maa.mp3';

/*6b works */ select * from test.test where filename like '%\Abaji\\Oriental Voyage\\11 maa.mp3';

/*6c works not */ select * from test.test where filename like '%\\Abaji\\Oriental Voyage\11 maa.mp3';

/*6d works */ select * from test.test where filename like '%\\Abaji\\Oriental Voyage\\11 maa.mp3';

/*7 works not */ select * from test.test where filename like '%\Oriental Voyage\%';

/*7a works not */ select * from test.test where filename like '%\\Oriental Voyage\%';

/*7b works */ select * from test.test where filename like '%\Oriental Voyage\\%';

/*7c works */ select * from test.test where filename like '%\\Oriental Voyage\\%';

[Ritesh]

Mr. Lachlan Mulchahy of MySQL AB says:

Quote:

The problem with the above is not actually a bug in MySQL, it is actually an error in your query. This is tricky to understand, so I will try to explain it simply.

When you are using a query to match a LIKE clause the following occurs:

1. You issue the query: select * from tablename1 where id like 'M:\%'

2. The MySQL parser, strips out the slashes to leave only escaped characters. So the query looks like this:

select * from tablename1 where id like 'M:%'

3. The LIKE pattern matching parser, converts all escaped characters to their literal meanings — There is no meaning for an escaped % so this gets converted to nothing. The query then looks more like this:

select * from tablename1 where id like 'M:'

Note: This isn't exactly what occurs inside the server code, but more a good means of understanding how the escaped characters are working.

So the bottom line is that in order for you to match a literal '' within a like clause, you must escape once for the query parser, leaving you with '\' and then again for the LIKE pattern matcher, leaving you with '\\'.

In summary, the correct query for what you desire is as follows:

select * from tablename1 where id like 'M:\\%'

[peterlaursen]

wellllllll ….

I think they should consider inproving their doc's then!

but does it explain these examples with my data

Code:

/*5a works */ select * from test.test where filename like '%\Oriental Voyage\\11 maa.mp3';
/*5b works not */ select * from test.test where filename like '%\\Oriental Voyage\11 maa.mp3';

BTW: All the discussions originated from my problems using a windows filename as a PK with SJA. I don't believe that SJA uses WHERE .. LIKE ??

[Ritesh]

Quote:

I don't believe that SJA uses WHERE .. LIKE

It does and thats crux of all the problem 🙁

[peterlaursen]

From my examples it seems like it will be safe to always escape the -character like “\\” when used with WHERE … LIKE.

[peterlaursen]

found this:

http://bugs.mysql.com/bug.php?id=11594

is this related somehow to our SJA issue ?

(funnily enough it's about using concat_ws() with WHERE…LIKE and music data (though no -character involved!))

[Ritesh]

peterlaursen wrote on Jun 27 2005, 06:41 PM:

From my examples it seems like it will be safe to always escape the -character like “\\” when used with WHERE … LIKE.

Only when you have data like yours i.e. data with .

[Ritesh]

peterlaursen wrote on Jun 28 2005, 01:34 AM:

found this:

http://bugs.mysql.com/bug.php?id=11594

is this related somehow to our SJA issue ?

(funnily enough it's about using concat_ws() with WHERE…LIKE and music data (though no -character involved!))

Nope.

This is a different kind of query.

[peterlaursen]

I shall try to hold back a little, but I believe this is too interesting …

I now believe that I understand that to search for literal string 'Oriental Voyage11 maa.mp3' where there are no chrs after “mp3”

you must write ” … like '%Oriental Voyage\\11 maa.mp3' ” in the WHERE-stmt

/* 1: – it works here */

select artist, albumtitle, title, filename

from test.test where filename like '%Oriental Voyage\\11 maa.mp3'

/* returns

artist albumtitle title filename

---

---

---

---

Abaji Oriental Voyage maa M:MusicAbajiOriental Voyage11 maa.mp3

*/;

/* 2: – but not here */

select Kunstner, Albumtitel, Titel, Filnavn

from musik.test where Filnavn like '%Oriental Voyage\\11 maa.mp3'

/* returns nothing */;

/* 3: – but adding a trailing % gets result. I really don't understand this! */

select Kunstner, Albumtitel, Titel, Filnavn

from musik.test where Filnavn like '%Oriental Voyage\\11 maa.mp3%'

/* returns

Kunstner Albumtitel Titel Filnavn

---

---

---

---

Abaji Oriental Voyage maa M:Peters MusikAbajiOriental Voyage11 maa.mp3 */;

/* create statements are identical or am I blind ? */

/* create statement for musik.test */

CREATE TABLE `test` (

`Kunstner` varchar(255) default NULL,

`Albumtitel` varchar(255) default NULL,

`Titel` varchar(255) default NULL,

`Filnavn` varchar(255) default NULL

) ENGINE=MyISAM DEFAULT CHARSET=latin1

;

/* create statement for test.test */

CREATE TABLE `test` (

`artist` varchar(255) default NULL,

`albumtitle` varchar(255) default NULL,

`title` varchar(255) default NULL,

`filename` char(255) default NULL

) ENGINE=MyISAM DEFAULT CHARSET=latin1

;

/* tried with and without PK's – and even tried renaming columns to identical names */

/* the only difference I can see with data and SQL in case 1 and 2-3 respectively is */

select count(*) from musik.test /* returns 38326 */;

select count(*) from test.test /* returns 1* /;

[peterlaursen]

Yes I was somewhat blind

but

CREATE TABLE `test` (

`artist` varchar(255) default NULL,

`albumtitle` varchar(255) default NULL,

`title` varchar(255) default NULL,

`filename` char(255) default NULL

) ENGINE=MyISAM DEFAULT CHARSET=latin1

;

and

CREATE TABLE `test` (

`artist` varchar(255) default NULL,

`albumtitle` varchar(255) default NULL,

`title` varchar(255) default NULL,

`filename` varchar(255) default NULL

) ENGINE=MyISAM DEFAULT CHARSET=latin1

(char –> varchar) yields same result!

all 3 queries were tested with SQLyog and Command-Line client as well.

But after adding some trailing blanks to that single record (there weren't any from the start) and removing them again even /*2*/ gets data !!

[Ritesh]

peterlaursen wrote on Jun 27 2005, 05:44 PM:

Code:

/*5a works */ select * from test.test where filename like '%\Oriental Voyage\\11 maa.mp3';
/*5b works not */ select * from test.test where filename like '%\\Oriental Voyage\11 maa.mp3';

Nope.

I gotta ask the MySQL AB people on this issue.

[Ritesh]

Quote:

(char –> varchar) yields same result!

CHAR and VARCHAR just defines how the data is stored in the disk. Otherwise, there is no difference in the implementation.

[peterlaursen]

well I thought I understood

starting with

select * from test.test where filename like '%\Oriental Voyage\\11 maa.mp3';

stripped by the parser >>

select * from test.test where filename like '%Oriental Voyage\11 maa.mp3';

evaluated by MySQL server >>

select * from test.test where filename like '%Oriental Voyage11 maa.mp3';

should find one record!

starting with

select * from test.test where filename like '%\\Oriental Voyage\11 maa.mp3';

stripped by the parser >>

select * from test.test where filename like '%\Oriental Voyage11 maa.mp3';

evaluated by MySQL server >>

select * from test.test where filename like '%Oriental Voyage11 maa.mp3';

should find nothing.

That's how it works with the test.test table in above example – but not with the musik.test table!!

Most crazy: adding trailing blanks, saving and removing trailing blanks it works with musik.test too!

Is there some non-visual “binary garbage” in the table ?!

[peterlaursen]

Quote:

Otherwise, there is no difference in the implementation.

I know. But I just wanted to make the cases are TOTALLY identical !!

[Ritesh]

I guess they need to update their docs on LIKE clause and usage. I will research on your problem a little more and let you know the details.

[peterlaursen]

BTW: I have also tried some experiments with putting where-clause in HAVING and INSTR()-function.

select kunstner, albumtitel, titel, filnavn

from musik.test having filnavn like '%Oriental Voyage\\10 Tchai.mp3'

/* doesn't find data */;

select kunstner, albumtitel, titel, filnavn

from musik.test where filnavn like '%Oriental Voyage\\10 Tchai.mp3'

/* doesn't find data */;

select kunstner, albumtitel, titel, filnavn

from musik.test Where Instr(filnavn,'Oriental Voyage\10 Tchai.mp3')

/* NB: finds data !!!! NOTE: LIKE-parser not active with INSTR!! I stille believe there is a problem with the parser*/;

select artist, albumtitle, title, filename

from test.test where filename like '%Oriental Voyage\\11 maa.mp3'

/*finds data*/;

select artist, albumtitle, title, filename

from test.test having filename like '%Oriental Voyage\\11 maa.mp3'

/*finds data*/;

select artist, albumtitle, title, filename

from test.test where Instr(filename,'Oriental Voyage\11 maa.mp3')

/*finds data*/;

/*(Now I can't use file ” …11 maa.mp3″ to test with music.test anymore – hope you understand that point!*/

[peterlaursen]

Quote:

I will research on your problem a little more and let you know the details.

Thanks. But I found a workaround long ago (exporting an Access binary replication type to a MySQL char/varchar type that can be used as a PK as well). So it should not be done for my blue eyes! For your own (if you have them blue 😀 ). As long as this behaviour is not completely understood you can't know what errors it will generate in the future. It could very well be very critical errors with corruption of data. Untill now the only error that has occurred with SJA is that no sync took place where it should. But no guarantee for the future!

And remember: user “Davowb” had an issue where SJA would work with an empty target, but not a target with data in it (what was also my experience). My intuition tells me that this is part of the same problem. And yes: I am a very intuitive person. Even more than most women! And I have pretty good results with it!

[peterlaursen]

However (just like before)

select kunstner, albumtitel, titel, filnavn

from musik.test having filnavn like '%Oriental Voyage\\10 Tchai.mp3%'

/* finds data */;

select kunstner, albumtitel, titel, filnavn

from musik.test where filnavn like '%Oriental Voyage\\10 Tchai.mp3%'

/* finds data */;

See attached pic. You can see the cursor. It's moved as much rightward as possible, which tells that there are no trailing blanks! So that's not the reason why the trailing %-character is needed in WHERE..LIKE!

[peterlaursen]

I just did a test with data on my webhost (MySQL 4.0.24).

upper SQLyog-window: “production”-database. Data imported with SQLyog from text-file. See complete DATA-history above!

Edited:

Quote:

Synced aprox. 4 times with SJA.

Wrong!!! I did a fresh import about two days ago to test the “export NULL” issue. SJA has not been in use with these data!

lower SQLyog-window: database with one row of data entered from the keyboard into SQLyog DATA-pane..

[peterlaursen]

then look here !! There IS some “binary garbage” at the end of data in file that has been imported from text-file. There is not when data is entered from keyboard.

Thus the problem with the trailing % is not related to the the WHERE…LIKE problem

[peterlaursen]

And it is something equivalent to EXACTLY one character that is at the end.

[peterlaursen]

I believe I can now understand, predict and verify the behaviour of all the example queries that I posted here.

Some examples are allready given.

here some of the most tricky ones:

/* First this one */

select * from musik.test where filnavn like '%\Oriental Voyage\%'

stripped by parser >>

select * from musik.test where filnavn like '%Oriental Voyage\%'

evaluted by Mysql server >>

select * from musik.test where filnavn like '%Oriental Voyage%' /* O simply resolves to O and \ to (literal) */

/* finds all tracks in album */

/* This however: */

select * from musik.test where filnavn like '%\Oriental Voyage\%'

stripped by parser >>

select * from musik.test where filnavn like '%Oriental Voyage%'

evaluated by MySQL server >>

select * from musik.test where filnavn like '%Oriental Voyage%' /* trailing % is here LITERAL % and O simply resolves to O */

/* finds nothing since there is no literal instance of 'Oriental Voyage%'*/

/* And finally */

select * from musik.test where filename like 'M:\Music\%'

stripped by parser >>

select * from musik.test where filename like 'M:Music\%'

evaluated by mySQL server

select * from musik.test where filename like 'M:Music%' /* M simply resolves to M */

/* finds nothing since there is no literal instance of 'M:Music' */

[peterlaursen]

My conclusion:

Parser is OK (you might even find it logical!), but error with data import (trailing “invisible” blanks)!

Since that is reproduced with 4.0.24 and 5.0.7 I really doubt that this is an issue with MySQL.

[Ritesh]

Quote:

Parser is OK (you might even find it logical!), but error with data import (trailing “invisible” blanks)!

I will give a detailed report on this issue by evening.

[peterlaursen]

I shall shut up until then!

I am fully confident that you will solve the problems

…………….. – with some help :wub:

[Ritesh]

If you check the SQL file for your table dump, you will see that there is an extra at the end of each primary key data.

I am not sure how that extra NULL got into the data. That is up to you to investigate.

Now in computer terminology, a string is always NULL terminated i.e. the end of a string is represented by a 0 value. When you see the text in SQLyog, it ends at the correct position because the extra NULL is represented as end of string but internally MySQL is keeping it as a part of data. Thus the WHERE clause fails.

How the extra NULL character came into place is a mystery 😮 Whether it appeared during import from MS Access or somewhere else – I have no clue 😮

[peterlaursen]

Quote:

SQL file for your table dump

which dump ?? Anyone special you looked at? From the server or one of the files that I attached ?

Quote:

you will see that there is an extra at the end of each primary key data

Yes – I noted myself in one of my postings that there was a mysterious “”

Quote:

Thus the WHERE clause fails.

Some of them. Others fail because of escaping style not taking WHERE .. LIKE filtering into account

Quote:

That is up to you to investigate

Any proposals for a methology ?

[peterlaursen]

Confirmed!

I did a fresh import.

created a small table with 1 row like

Code:

create table pl select url from track limit 1

Row url is the name of the one that I use to rename to filnavn/filename

Row is imported as BLOB, I convert to varchar(255)

Then export and open .sql-file in editor shows

/*

SQLyog Enterprise v4.07 BETA 2

Host – 5.0.7-beta-nt-max : Database – musik

*********************************************************************

Server version : 5.0.7-beta-nt-max

*/

create database if not exists `musik`;

USE `musik`;

/*Table structure for table `pl` */

drop table if exists `pl`;

CREATE TABLE `pl` (

`url` varchar(255) default NULL

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

/*Data for the table `pl` */

insert into `pl` values ('M:\Peters Musik\Duke Ellington\Jump for Joy\05 Jump for Joy.mp3');

If I don't convert to varchar but dump the BLOB result is the same.

Next tested with MySQl 4.0.24. Same result!

Next I tried to export form Access into MySQL (uses another (myODBC) ODBC-driver).

also produces insert into `pl` values ('M:\Peters Musik\Duke Ellington\Jump for Joy\05 Jump for Joy.mp3')

Tried with a few more columns and other colums imported as BLOB show same defect when data are automatically generated by player (read from mp3 file-tags for instance). Data imported as varchar never show this defect.

It must be a defect with data inherited from Access. And only data automatically generated by player (read from filesystem or file-tags for instance) show this defect – not when entered from keyboard into Access from Musicplayer GUI (“media library”).

So Sqlyog is not to blame. Musicplayer is.

Just One Correction: This column is not imported as PK. It might have been with some example posted. But in that case PK was created later.

[peterlaursen]

I tried to illustrate the principle of parsing of a query using WHERE .. LIKE

[peterlaursen]

Finally I shall point out that this “” mismatch is not the reason for the failure of SJA to sync with “filename” as the PK. Simply because data on both hosts have this defect and thus the concat_ws() function will still return same result on both hosts. The failure of SJA is because of escaping style produced by SJA not taking WHERE .. LIKE filtering (“parsing”) into account.

Nevertheless I shall regret the confusion spread by me here and the time wasted … 🙁

[peterlaursen]

maybe this is most illustrative:

/*this is correct */

/*************/

select 'backs\ash' like '%\\%'; /*returns 1*/

/* after stripped by LIKE-parser >> */

select 'backs\ash' like '%\%';

/* MySQL server pattern match actually check for >> */

select 'backsash' like '%%';

/*checks if -character is contained in literal string 'backsash' */

/* These are all wrong and return 0 */

/*****************************/

select 'backs\ash' like '%\%';

/* fails with LIKE-parser – like '%\%' becomes like '%%' after being stripped by parser

so with MySQL server pattern match it checks 'backsash' for match with “wildcard-meaning-% followed by literal-%” */

select 'backsash' like '%\\%';

/* fails with MySQL server pattern match – 'backsash' simply resolves to 'backsash' with MySQL server pattern match */

select 'backsash' like '%\%' ;

/* fails with both –

checks 'backsash' for match with “wildcard-meaning-% followed by literal-%” */

Goodnight from here – dream sweet 😆

[Ritesh]

peterlaursen wrote on Jun 22 2005, 04:34 AM:

This one should be better:

there are now 17 rows in source, 14 in target.

Result with SJA:

Table SrcRows TgtRows Inserted Updated Deleted

========================= ======= ======= ======== ======= =======

`testsync2` 17 14 0 0 0

Total time taken – 1 sec(s)

Correct would be: 3 insert, 2 updates, 0 deletes

and still the same with an empty target: rows are inserted correctly.

Working closely with people from MySQL AB, we have been able to fix this issue. v4.07 BETA 4 which will be released tomorrow will have this bug fixed.

You can try the sync with data attached.

[peterlaursen]

I tested with this reduced dataset and result of sync is OK

(I shall doto some tests with more extensive dataset tonight).

But this message is wrong:

Sync started at Thu Jun 30 15:22:24 2005

Table SrcRows TgtRows Inserted Updated Deleted

========================= ======= ======= ======== ======= =======

`testsync2` 17 14 17 0 14

Total time taken – 1 sec(s)

[peterlaursen]

Doesn't work here! 😎

Did a fresh import to MySQL 4.0.24 (at localhost and webhost as well) of music data (you'll find a copy at my webhost )

executed these with the webhost (not your copy – mine only!):

update mp3_filer set kunstner = 'abaki' where kunstner = 'abaji';

# (17 row(s) affected)

delete from mp3_filer where kunstner like '%duke%';

# (626 row(s) affected)

Changed PK to “filename”

ran a sync with colums option: “filename” and “kunstner” and no SQL_WHERE.

result displayed:

Sync started at Thu Jun 30 16:32:21 2005

Table SrcRows TgtRows Inserted Updated Deleted

========================= ======= ======= ======== ======= =======

`mp3_filer` 38499 37873 0 0 17

Total time taken – 273 sec(s)

But I believe this display is wrong – it should be :

Sync started at Thu Jun 30 16:32:21 2005

Table SrcRows TgtRows Inserted Updated Deleted

========================= ======= ======= ======== ======= =======

`mp3_filer` 38499 37873 0 0 0

Total time taken – 273 sec(s)

(If I repeat exactly same job it keeps on displaying “17 deleted” and they can only be deleted once!)

However:

With your attached file I can see that filename is now exported as

'M:\Peters Musik\Abaji\Oriental Voyage\09 Kilmé.mp'

and not as

'M:\Peters Musik\Abaji\Oriental Voyage\09 Kilmé.mp3'

So I believe you “corrected” the defect with my data ?

So:

If you are perfectly sure that the failure to sync is because of the defect with my data, I believe it's not worth spending more time with it. But if you can propose a query or some other procedure to “repair” the defect “in batch mode”, I shal do that (something like changing to BINARY VARCHAR, remove the 0-character, and change back) !?

Changing PK to column “Guid” sync with columns_option = “Guid” and “kunstner” and no SQL_WHERE runs OK and even displays correctly

Sync started at Thu Jun 30 17:10:22 2005

Table SrcRows TgtRows Inserted Updated Deleted

========================= ======= ======= ======== ======= =======

`mp3_filer` 38499 37873 626 17 0

Total time taken – 569 sec(s)

BTW: I have one question here:

When using the “columns” -option will it then make any difference whether you specify the PK-column(s) or not ??

[Ritesh]

Quote:

However:

With your attached file I can see that filename is now exported as

'M:\Peters Musik\Abaji\Oriental Voyage\09 Kilmé.mp'

and not as

'M:\Peters Musik\Abaji\Oriental Voyage\09 Kilmé.mp3'

So I believe you “corrected” the defect with my data ?

So:

If you are perfectly sure that the failure to sync is because of the defect with my data, I believe it's not worth spending more time with it. But if you can propose a query or some other procedure to “repair” the defect “in batch mode”, I shal do that (something like changing to BINARY VARCHAR, remove the 0-character, and change back) !?

Yes, I changed the data and removed the extra .

The above issue is indeed important for sync. To get information about the different row in the source, SJA executes a SELECT * FROM … WHERE … query. Wiith the extra in the end, the query never returns the correct row of data and thus the changes are not done in the target.

[Ritesh]

Quote:

When using the “columns” -option will it then make any difference whether you specify the PK-column(s) or not ??

It wont make any difference as SJA will search for the primary key columns in the tables.

[peterlaursen]

thanks.

But I believe the issue I reported here at Jun 30 2005, 01:25 PM here is still open ?

[peterlaursen]

@ritesh

YEAH MAN …

simply exporting data (with 4.06 😛 ) replacing '.mp3' >> '.mp3' in a text-editor, importing to both host, then running these stmnts:

update mp3_filer set kunstner = 'abaki' where kunstner = 'abaji';

# (17 row(s) affected)

delete from mp3_filer where kunstner like '%duke%';

#(626 row(s) affected)

and then changing PK til “filnavn”

… sync returns:

Sync started at Thu Jun 30 20:13:48 2005

Table SrcRows TgtRows Inserted Updated Deleted

========================= ======= ======= ======== ======= =======

`mp3_filer` 38499 37873 626 17 0

Total time taken – 526 sec(s)

SO: issue confirmed fixed with +38.000 rows and PK containing -character

[peterlaursen]

Quote:

It wont make any difference as SJA will search for the primary key columns in the tables.

The GUI functionality does not seem to know that! If NO colums are selected it displays this error msg. Choosing the PK-column (and that alone) works fine (with SQL_WHERE operating on another column)!

[peterlaursen]

The workaround in my case to repair this defect with the data imported from Access is to run this SQL after import (faster than export/import and can be automated I hope with the soon-coming Scheduled ODBC-import -feature of SQLyog I hope)

Code:

UPDATE mp3_filer SET filnavn = TRIM(trailing RIGHT(filnavn,1) FROM filnavn);

.. just in case someone is still interested …

[Ritesh]

peterlaursen wrote on Jul 3 2005, 11:19 PM:

Quote:

It wont make any difference as SJA will search for the primary key columns in the tables.

The GUI functionality does not seem to know that! If NO colums are selected it displays this error msg. Choosing the PK-column (and that alone) works fine (with SQL_WHERE operating on another column)!

This behavior is correct. You have to atlease select one column to generate checksums to find the difference. What I meant is that you dont need to necessarily select a PK column in this list.

[peterlaursen]

1) Since it will ALWAYs use the PK-column(s) I don't see why I should need to specify it.

2) In this case I ONLY want to use SQL_WHERE. SJA should generate checksums only on rows that satisfy the SQL_WHERE condition (besides using the PK as it must do).

I don't find it logical.

It's not at all a big deal – rather cosmetic, but anyway a little bit confusing, I believe.

In my “White Paper” I wrote

Quote:

And what is the evalutation order of the PK and the and the SQL_WHERE conditions when they are all used? Or does that question make sense at all when put this way? If not how then to understand it ? Personally I am still a bit uncertain if I understand all aspects of it with the more complicated combinations of settings.

This is an example …

[Ritesh]

Quote:

Since it will ALWAYs use the PK-column(s) I don't see why I should need to specify it.

SJA always uses PK columns to get the unique row. If you dont specify the PK columns then those columns wont be used while generating checksums.

Quote:

In this case I ONLY want to use SQL_WHERE. SJA should generate checksums only on rows that satisfy the SQL_WHERE condition (besides using the PK as it must do).

It only uses the rows satisfied in the SQL_WHERE clause but you have to specify which columns to use to generate checksums.

Putting it succinctly:

PK columns are used to select the unique row. Selection of columns tells SJA to use specific columns for generating checksums. Since checksum generation is a CPU intensive work, you can skip BLOB columns if possible.

[peterlaursen]

I'll try rewrite it some way then:

transferred to my term “evaluation order” (with “evaluation order” I mean in logical terms. Code design may differ from that) that would mean:

1)

Evaluated first: SQL_WHERE. Selects rows that should be considered further in the proces. SQL_WHERE is executed on both hosts (what I think it should not with a one-way sync!) and any row on either of the hosts that fullfills the where-condition (and ONLY those rows) proceeds to next step

2)

Evaluated next: PK's of the rows selected with step 1).

If a row selected with 1) has a PK-value that exists on source only that implies insertion on target.

If a row selected with 1) has a PK-value that exists on target only that

… with a one-way sync: implies EITHER deletion on target OR no_action_taken (depending on whether “never delete” – option is set)

… with a two-way sync: implies insertion on source.

If a row selected with 1) has a PK-value that exists on both hosts that means: proceed to step 3.

3) Evaluated last: With rows that has got as far as here checksums are calculated with the selected columns on both hosts. If checksums are identical nothing is done – if checksums not identical source_overwrites_target OR no_action_taken (depending on whether “never delete” – option is set)

This I must consider this a “popular” description

Quote:

Since checksum generation is a CPU intensive work, you can skip BLOB columns if possible.

That's trivial to me and you should know! It is not a matter of what to skip but what to choose (or put another way: not a matter of WHAT NOT TO DO but WHAT TO DO)!

Couldn't you show it ALL with some diagram ?? (If you can't you haven't understood either! 😛 )

So that we won't have to be fed with small bite's from time to time ? Try to think not as a developer but as a user 😀

I really ask you to be VERY precise and detailed ….

[peterlaursen]

I also wrote:

Quote:

I’d like a critical review of the XML generating GUI provided with SQLyog. Most

(graphical) objects here are too small to my taste. “Real life data” could have very long

identifiers/names and there could be dozens of columns with each table. When that is the

case the GUI is not optimal to work with as of now.

I can add that the GUI could be much more intuitive as far as use of and goes.

I'm thinking about the dialogue below in particular. I believe I can handle it now, but with the current doc's and GUI standard you will continue to see new users confused when getting to some more advanced use of the sync feature.

A detail: name of last column in the “columns column” of this GUI is truncated.

'kunstne' should be ''kunstner' (is in the XML-file).

[peterlaursen]

this for instance I would find much more logical.

I would have saved hours in my effort to understand it if only it was like that.

[Ritesh]

Very strange. I am not able to reproduce the column truncation error.

[Ritesh]

And now….

[peterlaursen]

Did you produce the XML-file using the GUI ? I seems that it occurs when a job file is opened and saved again from GUI. Here the error actually “writes back” to the jobfile!

Code:

localhost
******** ******** 3306 musik

http://www.deepeter.dk/SQLyogTunnel.php
-2101821

mydb1.surftown.dk
******* ******* 3306 jazcyk_guestbook

`mp3_filer`
`kunstne`

and next open truncates once more:

(I shall try to produce a “straight” reproduceable case)

[peterlaursen]

Here it happens like:

0) Start SQLyog

1) Create job-file using GUI

2) Save (don't run – don't schedule)

3) Open database sync. wizard again and choose the newly saved file

4) Step through and it displays as below

Jobfile content

Code:

localhost
******* ******* 3306 musik

http://www.deepeter.dk/SQLyogTunnel.php
30000

mydb1.surftown.dk
****** ****** 3306 jazcyk_test

`mp3_filer`
`Kunstner`

(UID and PW hidden)

[peterlaursen]

BTW (I continue asking ..)

jobfile says

Code:

GUI “Set Foreign_Keys_Check = 0 for target” is UNCHECKED.

To me this is the opposite world !?

How to understand this ?

[Ritesh]

peterlaursen wrote on Jul 5 2005, 02:38 AM:

this for instance I would find much more logical.

I would have saved hours in my effort to understand it if only it was like that.

I have been discussing this issue with my developers for some time now. I think we need to really improve upon the documentation and the GUI design of the wizard. We plan to sit on it make some changes to it for v4.2.

[peterlaursen]

Quote:

my developers

If you OWN them just tell them what to do … or sell them! 🙄

(cheap enough and I might buy …)

I believe that it a common problem that people involved in the development proces and other people sometimes have difficulties in communicating. When you have been working with some stuff for weeks and months you easily forget that what is obvious to you is not to other people.

I believe GUI issues are an important part of BETA-testing.

We have had similar discussions on the “save to clipboard” and “export as CSV” – GUIs for instance.

[Ritesh]

BTW, you havnt replied to my mail about yesterdays SJA bug fixes. Did you receive my mail?

[peterlaursen]

Quote:

Did you receive my mail?

NO! Or I could have deleted it occasionally.

Did you use the gmail or the other ([email protected]) ?

Try the latter.

[Ritesh]

Sent again to the latter email.

[peterlaursen]

that explains …

I just received a mail (my mail-client is Outlook 2000), but Outlook crashed after receive and dropped it.

I must have been your mail. I haven't particularly safe security settings, so don't really understand.

If there are any attachments, have you zipped them ?

Alternatively let me download …

[peterlaursen]

I just checked the mail-server at my ISP. It is not there anymere.

[Ritesh]

Just sent you a PM!

[peterlaursen]

Got it. I can spare about 45 minutes testing. That should be sufficient!

[peterlaursen]

it's running now.

In the meantime I have an issue with the installation script. It deleted my collection of XML-files!

Does it just cleanup the folder ? It should only delete SPECIFIC files (yours), not MY files!

[peterlaursen]

I can say that it still does not work from GUI. But from commandline 1 of 3 tests completed succesfully.

The GUI-problem could be the same as the TRUNCATE-issue (failure to parse the XML ?)

[peterlaursen]

YES!

RC3 works as it should with these data. 😀

I tested with 3 different PK's

*field 'filnavn'

*field 'Guid'

*an autoincrement integer PK (that I wouldn't normally have with these data).

[peterlaursen]

A very crazy thing happens:

I can't change a varchar(25) to a char(25) on my webhost:

HISTORY says:

alter table `jazcyk_guestbook`.`mp3_filer` ,change `Guid` `Guid` char (25) NOT NULL

and msgbox “Alter table successfull* appears.

But type does not change (or it is changed back)! It probably is a server issue and not a SQLyog issue. But it never was like that before. Maybe my webhosting company can't spare the money for a new harddisk ? 😮

[peterlaursen]

Quote:

RC3 works as it should with these data.

to put it clear: from command-line only, not from GUI!

[peterlaursen]

the ALTER TABLE from VARCHAR to CHAR can't be reproduced with tunnelling on my local machine.

So it must without doubt be a server issue.

But anyway – they may store it on disk as they like!

[Ritesh]

peterlaursen wrote on Jul 5 2005, 09:15 AM:

Quote:

RC3 works as it should with these data.

to put it clear: from command-line only, not from GUI!

Very strange.

Can you mail me the XML file and the screenshots of the GUI wizard?

[Ritesh]

I have downloaded the file. I will run a test on it.

[peterlaursen]

I removed attachment again (forgot to hide connection details to my webserver admin account) 🙁

[Ritesh]

Sorry but my mistake I removed the post because of the same reason.

[peterlaursen]

Did a complete reinstall. No change

I have been able to produce these crazy XML-files

Code:

localhost
****** ******* 3306 musik

http://www.yourdomain.com/SQLyogTunnel.php
30

localhost
****** ****** 3306 test

`mp3_filer`
`Kunstne`

In this case I chose a connection that works – and it writes http://www.yourdomain.com/SQLyogTunnel.php

Code:

localhost
********* ********* 3306 musik

http://deepeter.dyndns.dk/SQLyogTunnel.php
30

localhost
******* ******* 3306 test

`mp3_filer`

(In this latter case I REALLY selected a column!)

I might have been stepping frward and backward in the GUI … remember that produced the ´´´´´-bug too!

[peterlaursen]

I found out that this

Quote:

Sync started at Tue Jul 05 13:23:28 2005

Table                      SrcRows  TgtRows  Inserted  Updated  Deleted

=========================  =======  =======  ========  =======  =======

`mp3_filer`                  38499    38499         0        0

Total time taken – 2 sec(s)

happens when this

Code:

http://www.yourdomain.com/SQLyogTunnel.php

is executed!

please note that http://www.yourdomain.com exists!

[peterlaursen]

does not work (not on command-line either)

Code:

localhost
****** ******* 3306 musik

http://deepeter.dyndns.dk/SQLyogTunnel.php
30000

localhost
******* ******* 3306 test

`mp3_filer`
`Kunstner`

works

Code:

localhost
********* ********* 3306 musik

http://deepeter.dyndns.dk/SQLyogTunnel.php
-64771

localhost
******** ******** 3306 test

`mp3_filer`
`Kunstner` kunstner like '%'

how comes different timeouts ?

BTW: I remember an old thread in the Forums where some user had to specify a 'dump' SQL_where to get option work

I got to stop now! should have been 45 minutes – became 3 hours ….

[peterlaursen]

Just for your information:

Now I have the most terrible problems sync'ing with target on lacalhost. In one case SJA inserted 500 lines of garbage into the base before it crashed.

One-way sync from localhost to webhost still works … at least from commandline or from GUI when file not saved …

Actually I'm in doubt about how much of the problems are new …

[peterlaursen]

BTW:

I had your first mail this afternoon ( danish time 13:11 )

it is sent yesterday 17:27 (I believe that's Danish Time, too – mail systems should be smart enough to convert time zones).

It is a problem with some mail server on your side, I believe. It also happens often with notifications from the Forums. First I had suspected that it was my gmail – but they assure me that though it is not as fast as a normal POP3 account, delay would very rarely be more than a few minutes.

[Ritesh]

Quote:

I might have been stepping frward and backward in the GUI … remember that produced the ´´´´´-bug too!

This was fixed long back.

Quote:

Actually I'm in doubt about how much of the problems are new …

This is very strange because we have not changed any code regarding data sync except the LIKE and WHERE clause bug-fix. I am waiting for your dump. These errors are giving me goosebumps!

[Ritesh]

I had mailed and PMed you regarding a ZIPed dump of your mp3_filer table so that I can restore it at my local MySQL server and run on the sync. Did you get it?

[peterlaursen]

Quote:

I am waiting for your dump

what are you waiting for ? I thought I gave you all you asked !?

[Ritesh]

You have a PM!

[peterlaursen]

Quote:

You have a PM

I know! PM (Peter Madsen) is a chess-player at the local chess-club just as I. I know him very well! 😛

[Ritesh]

Looks like everybody in your town is named Peter.

[Ritesh]

peterlaursen wrote on Jul 5 2005, 11:28 AM:

I found out  that this

Quote:

Sync started at Tue Jul 05 13:23:28 2005

Table                      SrcRows  TgtRows  Inserted  Updated  Deleted

=========================  =======  =======  ========  =======  =======

`mp3_filer`                  38499    38499         0        0

Total time taken – 2 sec(s)

happens when this

Code:

http://www.yourdomain.com/SQLyogTunnel.php

is executed!

please note that http://www.yourdomain.com exists!

Very strange.

I am not able to reproduce any bugs with SJA except the above bug and the GUI bug. We will be releasing 4.07 RC4 later tonight which will have this two bugs fixed.

[peterlaursen]

Let us conclude on this long rather messy thread ..

Most important

1) There was a defect with some of my data having double “end-of-string” ('') characters

2) There was a bug with SJA that could cause failure to sync when PK was built on a char/varchar -column containing the backslash ( '' ) -character (such as a windows' filename)

3) Sometimes the GUI would fail to drop using a tunneled connection when opening an existing XML-file with a tunnel spec. from GUI

It's all fixed with 4.07. No reason for concern with SQLyog 4.07.

It has been very diffucult here to “sort out” or “isolate” each issue. Ritesh and I have been working on this intensively for almost a week. My PM-mailbox is filled up with correspondance about this… But it was worth it

😀

[Ritesh]

😀 😀

[Author]

Posts