[peterlaursen]

Yes …

and you are perfectly sure that you specify the correct port?

also try disabling firewall. some firewalls block connection with TCP even to 'localhost'

If you are good at Belgian-Flemish then there is something here:

http://forum.kuleuven.ac.be/read.php?f=31&i=884&t=884

(no solution, but same problem)

This error 2003 is an error that is generated by the mysql client code (the C-API) that is compiled into sqlyog. MySQL and not Webyog is responsible for that code – just for clarity! But this is no help either, I know!

hmmm …

* check port is correct

* disable firewall and any similar sort of network security. Is there a built-in firewall in WinXP-64 like in XP ?

* try another client using same client code (Administrator, Query Browser)

[peterlaursen]

Some research:

http://www.google.com/search?q=error+10061…a&start=10&sa=N

Looks like this error is a TCP-error !!

I can get something similar (see attached) if I specify the wrong port.

And if the MySQL server is not running.

It is TCP-connection that can't be established.

I believe this is not an SQLyog issue.

You can try to test with another client such as 'MySQL Administrator'.

[peterlaursen]

Can you see if it is a

* MySQL error

* SQLyog error

* a Windows error

Please paste in the error screen!

[peterlaursen]

Is it a correct error number that you are writing?

Isn't there a (text)-message too.

That would make things easier if you wrote that!

It looks like it should be a 4 digit MySQL server error.

Am I right ?

Read also:

http://www.webyog.com/faq/5_8_en.html

http://dev.mysql.com/doc/refman/5.0/en/err…ges-server.html

If there was any issue with SQLyog on 64 bit platforms, I can't believe it would be a connection issue.

Please detail!

Also: SQLyog and server is running on the same computer ?

[peterlaursen]

That is a typical office PC. Just as Vygi's at work.

Tomorrow Ri Coder gets back from the palmy beachs of Goa to the dusty offices of Bangalore, so things are going to happen again 😀

There is no doubt any more that some issue with memory management was introduced with 4.2 Betas. Most surprising that so much time had to pass before anyone noticed.

[peterlaursen]

Quote:

the maximum length needs no more than 10 (codes and domains)

then I would recommend that you use a char(10) or varchar(10) for those fields.

BTW. InnoDB works fine with 4.1.x too. But it looks like a fresh server install solved the issue!

[peterlaursen]

BTW: what is the reason for using all those TINYTEXTs ?

A TINYTEXT is only 256 characteres according to

(http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html)

2^8 – 1 = 255.

so a CHAR or VARCHAR would probably be much better to use here (much more effective), where you will need INDEXES and CONSTRAINTS.

Read about string types:

http://dev.mysql.com/doc/refman/5.0/en/sto…quirements.html

[peterlaursen]

That SQL_MODE is 'NO_ENGINE_SUBSTITUTION'

read

http://www.webyog.com/faq/28_72_en.html

http://dev.mysql.com/doc/refman/5.0/en/server-sql-mode.html

I think the easiest thing to do here is to get “MySQL Administrator” and check the “support for INNODB” on ther Server Control .. Configure Service -tab. If Server configuration is under your control. Some ISP's disable INNODB.

Of course the server must be restarted, for the change to take effect

From SQLyog .. tools .. show .. variables you can see the current value for system variable “@@have innodb” Or you can use this SQL

Code:

select @@have_innodb;

[peterlaursen]

It is not an INNODB tale but a MYISAM table – it says:

Code:

ENGINE=MyISAM

Note what I wrote:

Please note that if INNOdb is not enabled with the server configuration than MySQL will 'silently' replace INNOdb with the default table type (that is probably MyISAM). You won't get an error than but a warning

If MySQL is ver.5 there is an SQL_MODE available so that an invalid table type used in ALTER TABLE statements will raise an error instead.

[peterlaursen]

Please paste in the 'create statement for the table' from the SQLyog OBJECTS-tab. It should look like

Code:

CREATE TABLE `currentusers` (          
               `uid` varchar(255) NOT NULL,          
               `starttime` int(11) default NULL,    
               `lasttime` int(11) default NULL,      
               PRIMARY KEY  (`uid`)                  
             ) ENGINE=InnoDB DEFAULT CHARSET=latin1

It sounds very much as if it is NOT an INNOdb table! And I don't think there is much that you can do wrong here 😉

Please note that if INNOdb is not enabled with the server configuration than MySQL will 'silently' replace INNOdb with the default table type (that is probably MyISAM)

What is the MySQL server version?

[peterlaursen]

This is a recent phenomenon!

I have SQLyog 4.1 and 4.2 RC1 installed as well!

With 4.1 I can't reproduce ANY of the 'memory-build-up' phenomenon's

With 4.2 RC1 it is similar to 5.x.

That is so for both of my systems.

This observation of vygi's

Quote:

… and only when Result tab is visible

is important I believe. There is a very-very-very-small build up when DATA-tab is active (a few KB's for each move), but it is MUCH MORE when RESULT-tab is active. And the more data that is stored with the RESULT-buffer the faster it builds up!

But still vygi does not experience that difference with his PC at office.

I still believe that it is related to the implemation of the graphics buffer – simply moving an empty SQLyog around makes memory use increase on some systems and not on others.

BTW: it is reproducable with Linux/Wine too! It is here the 'wine-preloader' proces that grows!

I also now can reproduce the 'destruction' – but only on my Athlon/Nvidia PC, not on my 'mini' that has a highly integrated MINI-ITX Motherboard with all VIA components. See attached. Also note the high memory consumption. The initial SELECT resulted in usage of about 20 MB physical and 20 MB virtual memory. The rise is reproduced only by 'moving around' the program window.

[peterlaursen]

I think we agree!!

This additional memory manager that I have starts freeing memoy when there is less than 25% free. And it frees the excess memory consumed by SQLyog. So that could be the reason that I don't see the destruction.

[peterlaursen]

Sorry .. yes I can reproduce some of it! But no 'destruction' phenomenon.

If I start doing some SELECt that occupies some 30-40 MB memory, then memory load increases for each maximization – also if I don't do anything else in between. And just moving program window also trigger more memory use

However there must be some significant memory load to start with to reproduce this! A freshly started program does not!

Also if I next issue a SELECT returning only one row, memory decreases, but not to the 'state of the beginning'. The 'build up extra' is still there.

But still: It is not a problem here! It does not cause any destruction, does not slow down program etc. And memory is freed when needed by another program. (however Swap-file used is not)

Atttached show Task Manager after some 'moving around' (first>>second)and nothing else

[peterlaursen]

@vygi

.. I think we all believed you all the time. Even you ….. 😛

But since I can't reproduce this, there must be some decisive differences of our system! You write

Quote:

when I resize its window….it has started to destroy itself and other windows….

I still think it is a combination of OS, Graphics driver and SQLyog, that results that memory used by graphics is not free'd. The 'destruction' could indicate that the OS/the driver does not know which memory adresses to read and write to and from.

About this Graphics System: how does it use memory?

I guess it uses 'shared memory' but allocated dynamically or statically?

Is there some kind of Video-shadowing set active in BIOS?

My miniPC has shared memory (too), but a 'fixed memory pool' is allocated at system startup.

I think I understood that you have tested at work. Do you have a chance to test with another PC at home or somewhere else? And maybe try another driver for the Graphics card?

All my tests done with SQLyog 5.02 beta.

BTW: This webiste where you upload those pictures have some 'dirty' popups that crash my browsers …

[peterlaursen]

As I have written elsewhere the office in Bangalore is closed down for a short New Year's Holiday. But they will show up again monday or tuesday. I think there is little more that we can do now.

@carltond: what is your Graphics?

[Author]

Posts