Hi,

I have both versions of SQLyog (6.55 and 6.07). The 6.07 is running in Windows and 6.55 is running in RedHat using Wine. As far as I can tell, the 6.55 in RedHat seems to be functioning well. But when I ran Synchronize Structure Tool and compared them with 6.07 and 6.55, they are giving different results. The 6.07 is giving the correct results while the 6.55 is really way off as if it is reading a very old database.

I'm verified that 6.55 is pointing to the actual database and I can see the actual difference in 6.55 but it doesn't seem to be reporting it. Could this be because it is running in Wine?

Are you aware of this kind of bug?

1)
Please understand that this kind of report is not usable for us! You need to describe things a reproducable way! This is words only. I can also give you a lot of words but it won't bring either of us anywhere ..

Could you attach a structure-only dump (an importable SQL dump please!) from both hosts to reproduce this? You may create a ticket if you want privacy. Please zip the files into one archive (you are not allowed to attach .sql files here).



2)
And in principle you should always check with latest version (now 7.02 final and 7.1 beta2) before reporting a bug. We cannot possibly fix issues in old versions anyway. If there is some bug in an old version we basically also do not care much (as we cannot do anything about it). We will reproduce in latest version and fix in next version. That is all we can!

I did not mean to frighten you away!

Please provide a test case for reproducing this! We will solve with priority then. But without further information we cannot do anything!

Actually, you are absolutely correct but due to some privacy of our data, I cannot send some dump sql.

I only have license key for 6.07 and 6.55 which is why I am not yet moving to the newer versions...

But here's what I did though, I installed version 6.07 on Redhat 3 using wine... It was a perfect installation. I used the Structure Sync Tool and here are the results.

Windows Installation of 6.07 and 6.55 using Structure Sync tool gave the same correct results.
Linux Installation of 6.07 and 6.55 -- both gave the same result when compared with each other but when compared with their Window's counterpart, they have the wrong result set.

But what I found interesting was when I was running 6.07 in Linux, it actually gave these messages a lot of times...

fixme:ntdll:NtLockFile I/O completion on lock not implemented yet
fixme:ntdll:NtLockFile I/O completion on lock not implemented yet
fixme:menu:SetMenuInfo MNS_NOTIFYBYPOS partially implemented
fixme:ntdll:NtLockFile I/O completion on lock not implemented yet
fixme:ntdll:NtLockFile I/O completion on lock not implemented yet
fixme:ntdll:NtLockFile I/O completion on lock not implemented yet
fixme:ntdll:NtLockFile I/O completion on lock not implemented yet

I think this is the key as to why the Structure Sync Tool is not working properly in Linux.

I do not think this is related. This is a plain Wine issue on that distro and with that Wine version. Wine sometimes generates lots of errors but they are not serious! Failures to generate correct sync script is not affected by such. If SQLyog can execute queries against MySQL and have results returned thers may be millions of OS-errors and warnings.


We do not require a DUMP with data. A *structure-only* DUMP will do. Without it we cannot do progres
Also: can you tell the MySQL version, and if it is 5.x+ please also tell if you make use for Stored Procedures, Triggers, etc.?

I'm attaching the two dumps file... I'm including one table only for each database... So, in the structure synchronization tool, the first database is t1 and the second database t2 which has the missing field (missing_id)...

Here's the output of the synchronization tool,

/* Alter table in Second database */
alter table `t2`.`testme` COMMENT='';

If I use SQLyog 6.55 in Windows, it will give the correct result which is:

/* Alter table in Second database */
alter table `t2`.`testme`
add column `missing_id` bigint(20) NULL after `id`,
change `zipcode` `zipcode` varchar(255) NULL after `missing_id`, COMMENT='';

Here are some other relevant information:
MySQL 4.1.23
SQLyog 6.55
Red Hat Enterprise Linux WS release 3 (Taroon Update 7)
wine 0.9.59

I'm not using any stored procedures or triggers in MySQL.

Let me know other information that you need. Thanks.


t1_database dump:
/*
SQLyog Enterprise - MySQL GUI v6.55
MySQL - 4.1.23-pro-gpl-log : Database - t1
*********************************************************************
*/
/*!40101 SET NAMES utf8 */;
/*!40101 SET SQL_MODE=''*/;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
CREATE DATABASE /*!32312 IF NOT EXISTS*/`t1` /*!40100 DEFAULT CHARACTER SET latin1 */;
USE `t1`;
/*Table structure for table `testme` */
CREATE TABLE `testme` (
`id` int(11) NOT NULL default '0',
`missing_id` bigint(20) default NULL,
`zipcode` varchar(255) default NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;


t2_database dump:
/*
SQLyog Enterprise - MySQL GUI v6.55
MySQL - 4.1.23-pro-gpl-log : Database - t2
*********************************************************************
*/
/*!40101 SET NAMES utf8 */;
/*!40101 SET SQL_MODE=''*/;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
CREATE DATABASE /*!32312 IF NOT EXISTS*/`t2` /*!40100 DEFAULT CHARACTER SET latin1 */;
USE `t2`;
/*Table structure for table `testme` */
CREATE TABLE `testme` (
`id` int(11) NOT NULL default '0',
`zipcode` varchar(255) default NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;

Hi,
Thank you for your testcase. We reproduced at our end. We will look into the issue.


Regards,
Navya

This has been fixed in trunk now. Fix will be included in next 7.1 beta/RC release. Estimate is Tuesday next week.
If you are in urgent need for this fix now please contact us through the ticket system.

Quick question... I still have the 6.07 version... and I don't think our company will be getting the version 7.1 and above any time in the future... So, my question is whether there is a workaround for me if I don't get the 7.1 version?

nope! we cannot possibly fix issues 'backwards'. We strive to fix in first release after they have been reported. That is all we can do!

That's understandable. Just for curiosity sake, what was the problem on a high level though? Why was it working in Windows and yet it was not working with Wine in Linux?

Wine is supposed to be a port of the Win-32 API for Unix. The Win-32 API is a low-level collections of classes, functions etc. used to address/manage the basic functionalities of the Windows operating system

But the functions etc. in Wine sometimes work slightly different than the original Win-32 API. A common issue is that variables are not initialized exactly the same way. This you could call a bug in Wine - but as it exists we will have to code around it (sometimes however it will help if you update Wine!)!

Here we used functions to manage a tree-view GUI element .. and different from how we used those in versions before 7.0. There was such issue where the exact behaviour of the original Win-32 API and Wine was not quite the same.