[peterlaursen]

Your code is an SQLyog dump and it does not import VIEWs at all here, I see now, but generates 4 'allready exists' errors (when executed from SQLyog editor)

Please attach a mysqldump if you are sure that it imports everything correct!  we need to start with the same table as you have to reproduce.

[peterlaursen]

OK .. i have an idea.

Try open the lqlyog.err file in Notepad.  What encoding is proposed by Windows?  ANSI, UTF8 or something else?

I do not get such squares. with your file

[peterlaursen]

There seems to be more issues here!

1)  If you paste the file into the editor it imports (the error messages are ignored)

2)  I next export

3)  Open in editor and change the database name for the CREATE and USE statement!

4)  Trying to import from file returns:

Query:

/*!50003 CREATE TRIGGER `actualizarPrecio` AFTER INSERT ON `detallefact` FOR EACH ROW BEGIN declare IDP int default 0; select idProveedor into IDP from facturas where idFactura = new.idFactura; insert into mercproveedor (idMercaderia, idProveedor, precioU) values (new.idMercaderia, IDP, new.precioUnitario) on duplicate key update precioU = new.precioUnitario; update stock set ultimoCosto = new.precioUnitario where stock.idMercaderia = new.idMercaderia; DROP TABLE IF EXISTS `detallemov`;

CREATE TABLE `detallemov` (

`idMovimiento` int(10) unsigned NOT NULL DEFAULT '0',

`idMercaderia` int(10) unsigned NOT NULL DEFAULT '0',

`cantidad` int(10) unsigned NOT NULL DEFAULT '0',

`saldoStock` int(10) NOT NULL DEFAULT '0',

PRIMARY KEY (`idMovimiento`,`idMercaderia`),

KEY `FK_detMovIdMerc` (`idMercaderia`),

CONSTRAINT `detallemov_ibfk_1` FOREIGN KEY (`idMovimiento`) REFERENCES `movimientos` (`idMovimiento`) ON DELETE CASCADE,

CONSTRAINT `FK_detMovIdMerc` FOREIGN KEY (`idMercaderia`) REFERENCES `mercaderia` (`idMercaderia`)

) ENGINE=InnoDB DEFAULT CHARSET=latin1;

DELIMITER

Error occured at:2007-05-08 15:59:45

Line no.:165

Error Code: 1064 – You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 3

.. and nothing gets imported!  server version 5.2.3. It could be a server issue that the exported file is corrupt with this MySQL  (trigger code).  We will need to research a little more on this!

But the 'table …allready exists' is easy to see once you paste into the editor.´ And when importing from a file an error aborts the job.

Now exporting/importing VIEWs does normally work.  So there is something special with this case of yours that 'confuses' SQLyog.  We'll find out!

I attach the SQLyog dump I created with ver. 6.0 beta and MySQL 5.2.3.

BTW: you should absolutely update your MySQL server.  5.0.17 is pretty buggy!

[peterlaursen]

we will look into this.

You can always zip atttachments.  

[peterlaursen]

Verified as described!

[peterlaursen]

can you gvie a smal dump to reproduce with?

Also please inform about the server version!

[peterlaursen]

I cananot see anything wrong!

Could you arrange remote acces to that server.  We only need access to a 'silly' databases.

Do not write details here but create a ticket with details

[peterlaursen]

This is not expected behaviour, if I understand right!  

give us a little while to study that dump!

[peterlaursen]

Do I understand you right that those “tab chars” display as 'empty squares' ??

[peterlaursen]

If no database is selected there must

1) be is USE statement is the SQL file itself

2) be used 'full' syntax like ´database`.`table` in every statement referencing a table.

Did I understand right that the problem is that neither is the case ?

I think it would be very dangerous if settings or selections from the GUI were allowed to 'override' a USE statement in the file itself.

Also I do not think it is possible as the nature of SQL is sequential.  A USE statement will override any previous USE statement from the same connection. It is not SQLyog (the client) that does this but the server. We do not alter or even parse the content of such files. That is how SQL database server-client relations are designed to be, I think.

I do not understand “And in case no database is selected, SQLyog should use the database name from the dump.”

If that database is not in a USE statement where is it then? And again I think this is a request for server functionality, not client functionality.

Maybe it would be eaiser if you posted a (very) small dump.  Just to be 100% sure that we understand each others fully!

[peterlaursen]

I am not sure whether this MySQL bug affect only InnoDB. The example they use in the bug report is InnoDB, but the changelogs do not mention any specific table type!

We will look into your dump and other details tomorrow.

And from the charset path I can figure out that you are running a German localised Windows. Mine is Danish and as both are ANSI-western codepage I should be able to reporduce everythong that you experience, æ or ä and ø or ö makes no difference!

[peterlaursen]

If you have Foreign Keys you should use the option to

SET FOREIGN_KEYS_CHECK = 0

This is the standard way to handle this problem everywhere you copy/export/sync tables with Foreign Keys.

[peterlaursen]

I wonder if your problem could be an 'incarnation' of this bug with mySQL itself:

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

This is fixed only in the very latest releases (such as 4.1.22).  Is it possible for you to upgrade the server?

also please let us see the results of

Code:

SHOW VARIABLES LIKE '%character%';

[peterlaursen]

We have no such plans!

SQLyog is 'coded around' the MySQL C-client-API.  There is nothing like it for other databases really.  The MySQL SHOW statement (used extensively by SQLyog) has also no parallel elsewhere.

Your question has been asked before.  I think I use to reply that probably only around 30% of the existing code would go into a version for another databases, but only that much!  Some GUI code could be re-used but only that.  

I do not say that you will never see a Webyog product for other databases, but there are no plans fore a 'SQLyog for PostgreSQL' or 'SQLyog for SQL Server' or whatever – and no 'SQLyog for everything' either!

Basically there are two issues.

1) MySQL is probably the SQL database that differs most from the SQL standard!

2) the SQL standard is pretty weak/ little detailed on how to query 'metadata'-  And a GUI tool need to query metadata all the time.

… and as a result SQL databases are very differnt, except that they use (almost) the same language structure to query data!

[peterlaursen]

OK .. I overlooked the point that data were stored as TEXT.

Now with this table

CREATE TABLE `test2` (

`id` bigint(20) NOT NULL AUTO_INCREMENT,

`text` varchar(50) DEFAULT NULL,

`text2` text,

PRIMARY KEY (`id`)

) ENGINE=InnoDB DEFAULT CHARSET=latin1

I get the attached result.

Do you have different results with VARCHAR and TEXT types?

[Author]

Posts