[peterlaursen]

Just one question.

Quote:

use Windows 2000 and I often have a very busy desktop. When I have SQLyog open and I minimise it and then give SQLYog the focus back – it does not refresh its screen correctly.

Is SQLyog busy with something when you minimize it and give it focus back? then this could be because of the lack of multithreadedness too.

[peterlaursen]

I think we have two issues. One is related to SQLyog the other is not.

1) SQLyog is not multithreaded. So when it is busy with one job, it can't do anything else. Even not refresh the display of itself. If I understand you right that could explain this

Quote:

I have also noticed similar refresh/update issues when I have a long script or backup/restore running. As I have the smaller window showing how many records are being updated and number of queries run. If I move something over the window I loose that information and thus cannot estimate time of completion etc.

A workaorund could be to use “virtual desktops”, that are available for instance with most modern graphics drivers, so that you won't have to have another program window over sqlyog. There is not fix for lack of multithreadedness in 4.2. It is a COMPLETE revamping of the code.

However what you write in the beginning

Quote:

I use Windows 2000 and I often have a very busy desktop. When I have SQLyog open and I minimise it and then give SQLYog the focus back – it does not refresh its screen correctly.

is a problem with your system I believe. Som driver conflict maybe. Most likely a conflict between the graphics driver and some wireless (mouse, keyboard, wireless LAN). Of course I can't know, but I don't experience that with SQLyog and my 2 systems.

Do yo experience that on MORE ( and diffferent) systems? And no other program behaving like that?

You could try running the program in “failsafe” mode. That should eliminate most driver problems. Also try uninstall the graphics driver and use Windows' standard .. or the other way around … And try another Grapics card, if you have the chance.

It will be very diffucult to reproduce your problem.. It would take a complete “copy” of your system. OS, SP-level, drivers, hardware …

[peterlaursen]

You shoul read the program help file! 😀

“execute one query” and “execute all queries” are about queries in the Query pane (a Query Tab as of SQLyog 4.2). Here queries are delimited with the ; (semicolon) delimiter.

“execute one query” executes the query where the cursor is positioned.

“execute all queries” executes all queries on the active tab,

It has nothing to do with queries saved to disk! Only queries that are loaded into the Query pane.

[peterlaursen]

I don't think I am missing anything. If the source database returns DEFAULT = NULL when queried for the table definition (through ODBC) then the wizard writes NULL to the XML file.

This jobfile for instance:

Code:

localhost
root ******* 3306 test

test





no

is generated by the wizard of SQLyog 4.2 for attached Access database.

There are no superfluous default statements.

The defaults only come in the jobfile if the ODBC-driver and the source database return defaults when queried about table structure. Your source database and related so-called “ODBC”-driver tell SQLyog that the table definitons have defaults for those columns. And then of course SQLyog write it to the jobfile.

There are a lot of early database systems that came to existence before and the early years of the ODBC-standard (we are talking about the beginning of the 90'ties) that were later made “ODBC-compatible”. Most of them have non-standard-issues. I guess that is the problem here. But SQLyog has implemented workarounds for similar issues (and regular bugs) with other databases. I shal not exclude that there is one more of the kind possible.

[peterlaursen]

I just can add that problems also exist when tunnelling to a server running on windows.

[peterlaursen]

Or maybe rather a problem with the source database.

is it not possible to remove the DEFAULTS from the table-definitions on the source database (if they are there)? If the database implementation is so that DEFAULT = NULL is the only way to specify 'No default' then there is a problem! You never know what kind of “workarounds” have been made in the early ages of ODBC-implementation!

[peterlaursen]

But I got a copy of the file, after all!

It must be a problem with that ISAM database and ODBC-driver.

NULL is nonsense!

NULL is nothing. Default = nothing …. BVADR!!! 🙁

Now I think I got the point.

NULL !!!

It is not the default statement that is a problem. is OK, but NULL is not

Now with 5.0.13 MySQL is a little bit consequent but your ODBC-driver is not!

In my opinion it is not a SQLyog issue, but an issue with a poor ODBC-driver!

But let Ritesh have a look at it too!

[peterlaursen]

shawn!!!

Send that file to [email protected] and delete the attachement here.

Never expose your user credentials like this!

[peterlaursen]

i quote from that link:

Quote:

In the later versions of MySQL (maybe starting 5.x), you cannot set a default value to an “auto increment” field (if you think about it, it doesn't make much sense either).

That makes sense!

But you are sure that you did not specify some DEFAULT-value from the Migration Tool GUI yourself? I still doubt that an empty statement in the XML generally is a problem. But a 0 is with an autoincremented field.

[peterlaursen]

I think you mismatched the installer build!

Installation screen says beta4, but program help says beta 3.

And error persists!

😛

[peterlaursen]

Yes it is!

That is what the ODBC/Migration tool is for!

An extensive review of the tool here (that I wrote 🙂 )

http://www.databasejournal.com/features/my…cle.php/3550146

But you don't “import into SQLyog”. You “import into MySQL”. SQLyog is a MySQL client – not database in itself.

[peterlaursen]

Confirmed.

I get this error msg with 4.0.26 on local and 4.0.24 on remote:

Quote:

Error fetching target server version information.Error No. 12019

HTTP Error. Denne handle har en forkert status til den valgte handling.

Last half part is Danish and must be a Windows error-msg. Some protocol error.

Translation somewhat like “The status for this handle is wrong for the action specified”.

[peterlaursen]

Quote:

I tried the Enterprise version previously

Yes, that is why, I guess! If this is more than a month ago, your trial period has expired. Trial periods are for trying!

As the program is protected this way against so-called “piracy” as of now, you would not expect Webyog to publish how to remove that information from the system ??

You don't have a chance to install the trial on another computer for testing?

A fresh OS install will do too 😉

[peterlaursen]

I also googled a little and found this:

http://techrepublic.com.com/5100-10878_11-5148530.html

ISAM = Indexed Sequential Access Method.

It sounds like the DATAFLEX/POWERFLEX systems that I worked a lot with 15 years ago!

But probably not very relevant! After all data are transferred by the ODBC-driver.The key point is what SQL is generated by the SJA when interpreting the XML. And it is the “create table …” that fails for some reason.

[peterlaursen]

Quote:

I came across a post that said DEFAULTS should be removed when creating new tables in Mysql 5.x

That sounds strange! Of course a column could have a default-value. But of course empty default-statments in the XML does not create any default value with the database. When SJA interprets the XML I believe the is just skipped when the SQL is created. But Ritesh must confirm that!

I have been using MySQL 5 since 5.0.4 alpha I think, and never came across anything like it. Of course the new Migration Tool is new code, but I can't believe that it does otherwise than an ordinary “create table” statement.

You don't think you could possibly find that “post that you came across” again? I really would like to read what it says exactly, and what sources it references.

But send the XML to Ritesh at [email protected].

[Author]

Posts