[peterlaursen]

There are no 'named pipes' in Linux I think.  But there are 'sockets'. I do think however some distros ((k/x)ububtu ??)  has 'cloned' the Windows 'named pipes' concept.

It also depends on the client type.  With PHP 'localhost' will force a socket connection, 127.0.0.1 a tcp-connection. (the host file is overridden).  This should not be the case with the C-API as compiled into SQLyog and SJA.

But if you know more about those issues than I (and that would not be hard!) 

you are welcome to propose improvements to the FAQ's on connection issues!

[peterlaursen]

It is fixed in both the 5.x and 6.x development tree now.

Are you asking for a 5.x or 6.x build? We can give a 5.31 'not-releeased' and hope to release 6.0 beta 5 tomorrow.

Is it community/trial/enterprise you need?

[peterlaursen]

once you get back, plese try to rename the sqlyog.err file.  Next start SQlyog and send an invalid query.  Then a new .err file will be created!

[peterlaursen]

We have located the problem and your initial description was very close!

To handle situations where VIEWs are built upon other VIEWs (and taking into account that there is no way to control in what order the CREATE statements are added to the script), we need to build (temporary) tables to avoid an error occuring when trying to create a view built upon nother not (yet) existing view.

Those temporary tables (with 'viewnames') should always be deleted.  They only were when DROP VIEWS was checked.  And that was a bug really!

We will provide a build in the 5.x as well as the 6.x tree very soon with the fix. We will give links here when available. 

[peterlaursen]

well ..

of course all SQL commands could be written to a file instead of being executed at once.  However it could then easily occur that some commands would not run (or worse: create unwanted results) because the database(s) had changed between the calculation/script building and the execution time.

The SQL commands generated are 'primitive' INSERTS, UPDATES and DELETES only.

Do you request such feature?  and why?

[peterlaursen]

reproduced.

But the problem is that at the time of creating the DUMP we and SQLyog cannot tell how that dump will be used: executed over an existing database or not!

But let us consider if we can make this more intuitive or at least explanative!

[peterlaursen]

I think you are right.  If there exists no such database in advance (or if it is dropped), it should not matter whether drop view is checked or not.

We will just try ourselves to uncheck this option and see if we can reproduce then!

[peterlaursen]

Please give some details about the server and how you connect (direct, SSH, HTTP).

Does this occur completely random?  Is it happening even if there is no activity?  Any specific operation that seems to trigger this?

Also try to turn of auto-complete.  The error message can came form any running thread/connection – also the autocomplete thread!

[peterlaursen]

OK .. thx for the feedback.

Yes we should always remember that a computer can have a non-typical host's configuration!

[peterlaursen]

We can import your mysqldump, export with SQLyog and import again successfully.  Tested with MySQL 5.028 and above.  so for us it works.

How do we do progres from here?

Pls. copy and paste the export dialogue in here.

[peterlaursen]

We absolute do intend to support import of dumps created with any common client (mysqldump, MySQL Administrator, phpMyAdmin) with SQLyog.  Unlike for instance  MySQL Administrator that (officially!) does not support import of mysqldump's!

But there can be server compability issues with early 5.x versions.  As far as I remember it has to be 5.0.19 before it was given the predicate 'stable' – an how stable 5.0.19 really was can be discussed indeed!

It will take a few hours to analyze this in depth.  We will probably need to install old server versions.  That is no problem – it only takes a little bit of time.

Also I think I ow you an apology.  Actueally I think now that tables and views identically named never was possible. i think it would create a conflict in information_schema-tables and import of one would fail!

[peterlaursen]

It is a known issue.  We do not support  the BIT type- -whether bit(1) or bit(n)  (n can be up to 64).   Please refer to http://code.google.com/p/sqlyog/issues/det…mp;can=2&q= .  I suggest you try to map to a TINYINT when importing.  That is what MySQL before 5.x is doing.

I do not think you will ever be able to 'link back to access' from MySQL BIT types.  This is basically an issues with incompability between the MyODBC driver, MySQL and Access.  Access has no datatype similar to MySQL BIT.

And Why do you want to 'link back' ?  something you miss in SQLyog?

What is required is a true implementation of the standard SQL BOOL type.  Neither Access nor MySQL has (though Access is closer than MySQL!).  That is the basic problem!  MySQL BIT is not a boolean!  It is a numerical type using the binary number system.  In MySQL command line you enter a BIT(4) as for instance

Code:

b'1001'

.  This we should support in SQLyog and we should also display it like that! (what mysql command line client does not!)  Just as I think (my personal opinion) that a VARBINARY(8) should be displayed as for instance h'A0 34 F1 AA E7 2C 00 EA'  (h for 'hexadecimal') similar to common hex-editors .

So basically a BIT(1) is no better or 'more correct' substitute for a true BOOL than a TINYINT(1) is!!

Support for BIT type is priority once we get the first stable 6.0 release out!

[peterlaursen]

OK .. my mistake then.

Let us start with that mysql dump.  If that will import that will be the correct place to start!

We will start ananlyzing tommorow morning.  It is close-office time in India now!

[peterlaursen]

I mean the sqlyog.err file.  This is the SQLyog error log.  Error messages dispalyed on the screen are read form this file!

I there is nothing confidential can you copy, zip and attach the sqlyog.err file?

You may also tell if SQLyog 6.0 was installed on top of an older version.

And finally it would be nice if you could make a screenshot of that error message with such square, so taht we can see exactly what it looks like (as we never saw ourselves!)

[peterlaursen]

OK – I think we figured out.  You have TABLEs and VIEWs named identically.  Can you confirm?

That is not possible with recent MySQL versions.  Our code does not take that into account.  I also doubt that recent releases of mysqldump does.

MySQL 5.0.17 is NOT a stable version.  Once stable versions are out we do not support betas (or gammas or RC's or what they may be named) any more.

You may attach a mysqldump from your current server and we will see what happens when we import to a recent version

[Author]

Posts