[peterlaursen]

I cannot reproduce this!

Here I uncheck 'save password' and next time Connection Manager is opened pasword is not displayed.

And that no matter if program is restarted or not.

Are you perfectly sure that it is the latest version you are testing? (you might have installed to another folder and have an old icon / link and use it by mnistake)

[peterlaursen]

it does not change anything to 'hope' or guess

.. it is better to research and find the facts in whatever doumentation is available like:

http://webyog.com/en/whitepapers/Using_SQL…L_Databases.pdf.

It is written there and repeated in this Forums hundreds of times that when a row on either host has the same PK ,< source> will overwrite .  

Quote:

I would have thought that two way schronization would somehow compare the records and keep the most up to date one, possibly with user nominating a field in each table as the update?

“somehow compare” …

There is no way for a program to tell which row is the correct one if the PK is the same but content is different!  

There will need to be a “rule” defined by a human.

Currently there is only one “rule” available – and that is: “overwrites ”

but of course more rules could be added.  

Using 

 a TIMESTAMP .. ON UPDATE CURRENT_TIMESTAMP is one option,

 “do nothing with that row” is another 

 “dublicate this row” is a third solution

– all of which could be implemented – and that is actually what we actually plan to do.  We are considering how to build a user configurable 'conflict resolver' for such situations.

However the TIMESTAMP solution (and more sophisticated solutions) will require that the user has privileges on one on more servers that he might not have.  So I would say what we currently do is the basic solution.  Only SELECT, INSERT, UPDATE and DELETE privileges are required for the user.

[peterlaursen]

the problem is that when you are using the PUTTY the way that you describe it you are not tunnelling.  You are creating a shell from the remote machine on your local.  and that is something different.

From your description as I understand it everything you do seems correct.

There must be some issue with SSH tunnelling on the remote host.  You or your SysAdmin will need first to check whether TCP port-forwarding with SSH is enabled and functional on the host.

[peterlaursen]

The official policy on distributing old versions is here:

http://webyog.com/faq/33_128_en.html

What problems existed with 5.02 on some specific system(s) is not really interesting I believe.

Nobody will probably be able to reproduce and the code changes in between are so significant that it would not be worth the effort either.

 

Please provide a detailed report of problems with latest stable and/or beta/RC version! 

[peterlaursen]

I really do not know how to do progress with this.  I think there must be an issue on that server.

1) did you try explaining the problem to the SysAdmin/support (if there is such).  tell them that it used to work with other servers/hosts/ISP's

2) can we have temporary access to this server?  If so create a ticket with details.  We do not need access to your data.  Create a user and an empty database and give only access for this user to this database.

[peterlaursen]

@John:

1) please (always) tell what version you are using!

2) also explain more in detail when that happens?  Can you 'test connection' but not really connect?  Or does it happen (any arbitrary time) after connection has sbeen functional after a while

The error message 'Lost connection …' is a (standard) MySQL client error message.  It is the MySQL client code that is compiled into SQLyog that generates this error.  Not 'Webyog code'.

TCP port forwarding needs to be enabled in SSH configuration on the server, but it will be in 99.99% of cases.

First read:

http://webyog.com/faq/22_113_en.html

Is it possible that you could post (here or in a ticket) a screenshot of your connection settings?  Just fake of paint any confidential details.

[peterlaursen]

Reproduced with your example!  

There seems to be a problem when both the length fields and the 'UNSIGNED' descriptor are used at the same time.

We will wok on this tomorrow.

[peterlaursen]

Just for your info: 'Export as SQL' is mainly intended to be used from the RESULT tab, 'Backup as SQL dump' from the DATA tab.  'Export as SQL' was introduced lately due to user requests that wanted an option to export a RESULT (not a TABLE) as (some kind of) SQL.  Of course there cannot be any additional information like charset, engine, indexes, comments etc. here as there is no such information in the RESULT.

We will (have to) make this more clear with the next release, I think!

But the issue with NULL was a bug, of course.

I do not understand you when you write “because not print the atributtes of fields like permit null”.  

Please post a detailed example? screenshots, dumps are welcome.

[peterlaursen]

maybe your problem is related to this discussion:

http://www.webyog.com/forums//index.php?showtopic=3060

We are not sure if

1) you are getting your information by the (wrong infoin the) tooltip

2) key_blocks_unused is really returning the value thatyou are claiming

Could you post your “show global variables” and “show global status” dump

for a specific situation, and describe how you understand it

[peterlaursen]

This is fixed in 5.23 and 5.24.  Please upgrade!

BTW:  You should consider the difference of 'backup as SQL dump' and 'Export as SQL'.  Use 'backup as SQL dump' if you want to make a backup and want all table details etc.  'Export as SQL' is not intended for backup purposes.  It basically only 'embeds' data in INSERT statements.

[peterlaursen]

If you do not use transactions or Foreign Keys or any other specific InnoDB feature it will make no harm to try!

There is some discussions of InnoDB performance compared to MyIsam. In the beginning (MySQL 3.23 and 4.0) InnoDB could be vesy slow – with the later versions I do not think the difference is very big, but still I think it is slower.

[peterlaursen]

about the Query cache: you are correct that if only BOTH hit rate is low AND cache memory is used it makes sense to increase the total cache. Because then incresing the cache will probably also increase the hitrate.

We will release Monyog 0.16 by the end of this week including a fix for this issue and better advisors for the Query Cache in general.

The query cache distinguishes between queries a 'binary' way – even if you change the LETTERCASE the queries are considered different. Only when executing identical queries frequently it makes sense to enable the QC. Sometimes the advisor maybe should be 'disable the QC – you do not get anything in return for the CPU overhead that maintaining it generates'!!. Actually there is no general rule about what is good. On yahoo.com (where users do the same select again and again) anything less than 99% is probably bad – on other type of systems it may be different.

Your data: “that 56304 of 64000 1k blocks are not in use”. Now if every query uses 2 blocks in average you have stored (64000-56304) / 2 = 3848 queries in the cache. How many different queries were executed since the server was restarted? Also note that queries that return a TIMESTAMP is not cached (and there are a couple of handfull of similar exceptions). In your situation you could probably decrease the QC without any problems and without losing performance. But maybe your block size could be 'tuned' to fit your queries. Also note that a very big query executed once may 'prune' you QC completely. That can be avoided by using “SELECT sql_no_cache …” for such queries. What does “show status like 'Qcache_lowmem_prunes';” tell?

A good article at: http://dev.mysql.com/tech-resources/articl…uery-cache.html

about the MyISAM key cache: likely it is a similar issue. But we have posted a ticket with MySQL AB for gettings detailed explanation about some undocumented questions about this one. We will return when we got the answer.

[peterlaursen]

which program are you talking about? I think SQLyog and not Monyog?

(please post in the correct category next time!)

Issue is confirmed! It happens with 5.24 and 5.23 if you 'install over' older versions.

To correct the issue: delete/rename the sqlyog.ini file or just open the file in an editor and delete all passwords (every line reading like 'password ….').

We changed the storage of this password in 5.23 and made a mistake with 'old' passwords.

I am moving your post to SQLyog category!

[peterlaursen]

I think you misunderstand the operator hierachy!

67,108,864 + 50,331,648 + 524,288 + 1,048,576 + 16,384 + 20 * (520,192 + 520,192 + 1,048,568 +8,388,608 + 196,608 + 67,108,864 + 2,093,056) = 1716551.52

and

(67,108,864 + 50,331,648 + 524,288 + 1,048,576 + 16,384 + 20) * (520,192 + 520,192 + 1,048,568 +8,388,608 + 196,608 + 67,108,864 + 2,093,056) = 9509229106.1389

67,108,864 + 50,331,648 + 524,288 + 1,048,576 + 16,384 + 20 * (520,192 + 520,192 + 1,048,568 +8,388,608 + 196,608 + 67,108,864 + 2,093,056)

means

+ 67,108,864

+ 50,331,648

+ 524,288

+ 1,048,576

+ 16,384

+ (20 * (520,192 + 520,192 + 1,048,568 +8,388,608 + 196,608 + 67,108,864 + 2,093,056))

and not

(

+ 67,108,864

+ 50,331,648

+ 524,288

+ 1,048,576

+ 16,384

+ 20

)

* (520,192 + 520,192 + 1,048,568 +8,388,608 + 196,608 + 67,108,864 + 2,093,056) = 1716551.52

[peterlaursen]

yes this issue is known.

It is also fixed in the development tree. We will release 0.16 with this fix and similar small fixes soon – maybe even today.

We actually tested on IE 5.5+, Firefox 1.0+ (and the other Mozillas: 'Suite','SeaMonkey','Minefield') and Opera.

Firefox before 1.5 was a big problem actually, butwe finished that as well! Old/traditional Linux browsers (Konqueror most notably) won't work due to missing AJAX support.

[Author]

Posts