[peterlaursen]

They managed to get 5.1.9 out before the Users Conference.

Available from here for instance:

ftp://sunsite.dk/mirrors/mysql/Downloads/MySQL-5.1/

Still no installer for Windows. But everything seems to work like a dream. It will be FINAL this summer I guess. Quite impressive actually. And puts a little pressure on third-party vendors like Webyog <_<

[peterlaursen]

This posting is only additional info for those interested!

I may not be 100% correct what I wrote last. I overlooked one link in the chain, and that is XML-encoding! So for conversion of characters from a multibyte-storage to a single byte representation in the SQLyog workspace the XML encoding scheme must support those characters where XML-encoding applies (that is SJA operations). However it should still work as I described above it should still work with most latin-based charset and even cyrillic. But Arabic, Hebrew, Greek, Armenian etc. … well, I really don't know!

For those functionalities that do not use XML representation of data (export/import, copy to other host) I still believe that is is correct what I wrote.

[peterlaursen]

Is COALESCE available with MySQL 3,23 ?

http://webyog.com/faq/8_94_en.html

[peterlaursen]

I am afraid I don't understand what you mean with 'run as a job'?

Could you explain?

[peterlaursen]

It is no issue to insert the 'order by' into the database. You can do yourself. Common combinations could be added like 'select * from' etc..

BTW: I think user entries (priority settings, user's own keywords and phrases) should be in a seperate database file ideally …

[peterlaursen]

And I also VERY MUCH would like to be able to minimize a SQLyog instance when a sync is running. It is the same problem that we discussed before, that the popup windows steal focus from the main program window.

It is ANNOYING. Workaround is of course to use a Virtual Desktop manager.

[peterlaursen]

I second this .. but am unsure about the exact implementation.

Actually the manual 'Refresh' buttom should be supplemented with some automatic refresh-call …

It has to be analyzed!

[peterlaursen]

“not even as a part of a WHERE clause.”

But you do ?!

[peterlaursen]

With a PK like

Code:

CREATE TABLE `pladder` (
`id` bigint(20) NOT NULL auto_increment,
`t` varchar(50) default NULL,
`f` float default NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

there is no issue.

Without a PK like

Code:

CREATE TABLE `pladder` (
`id` bigint(20) default NULL,
`t` varchar(50) default NULL,
`f` float(6,4) default NULL — or another M,D setting (even plain nothing)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

I cannot reproduce an issue either, though I think it should be possible! And it annoys me that I can't 😡

Even this

Code:

update pladder set f = 10/3 where id = 1 — from SQL-pane
update `pladder` set `id`='1',`t`='dfd',`f`='44' where `id`='1' and `t`='dfd' and `f`='3.3333' — from GUI

does not raise an issue. And I dont understand because I think that f is not exactly 3.3333 internally and an error should arise.

@Vygi — comments? Can you create a definition and a sequence of SQL's generating an error when there is no PK ? (With a PK it should not be possible now)

[peterlaursen]

Yes it is true that it is OK in RESULT tab … I also noticed this …

[peterlaursen]

“SQLyog only uses PRIMARY KEY if its available.”

It does not. It was changed with 5.1 BETA1 or possibly BETA2.

I believe it is some confusion due to DEFAULTs implementation.

Check your mailbox! I pointed to this 3 weeks ago or more! 🙂

Or 2 months ago probably.

[peterlaursen]

I remeber the first program I wrote 30 years ago was for a TI calculator.

It went into an infinite loop because of something like

start

t=9

n = 1

:loop

t=t/3

n = n+1

if not t = 0,001 goto loop

output n

end

FLOATs in a nutshell … it could still have been executing the calculation '0/3' 5 times per second (that was fast !!!) if there still was power … maybe it does somewhere .. don't remember what happend to that machine 🙂

EDIT: Nope .. I remember – it was an OLIVETTI sized as an ordinary PC keyboard today – only 4 times higher! Cost around 2000 USD. We were two highschools sharing one of those… and it knew about FLOATS 🙂

[peterlaursen]

I think that in this case it only should use primary key

>> I have also wondered (and asked and protested actually!) why this was changed in 5.1. 5.02 used the PK. This is due to support for DEFAULT (such as CURRENT_TIMESTAMPs on update CURRENT_TIMESTAMP). Such columns should be omitted in the insert. But still PK should be used in the 'where' part. And in case there is no PK a FLOAT must be omitted in the 'where'. Because it is never = !! se below.

or am I wrong????

>>> no I think you are right. Floats are not 'accurate'. It could be 10.5000007 and that is <> from 10.50 and the 'where' is not fulfilled.

And as I told Ritesh: Imagine a 4 GB LONGBLOB in a WHERE … it is completely unneeded.

[peterlaursen]

No change with RC2!

[peterlaursen]

Is it possible to use/convert to a TIMESTAMP and not a DATETIME? I understood this bug does not affect TIMESTAMPs. Actually a bug in SQLyog affecting TIMESTAMP-based PK's were fixed early in the 5.1 BETA tree and 5.1 works fine with recent MySQL 4.1 5.0 and 5.1.

I think that we cannot mess around with the code, before we have some indication from MySQL what they intend to do for the future. Is this a plain bug? Or is there some reason that 'SELECT datatime_variable+0' must return a FLOAT and not a BIGINT?

But TRUNCATING to get rid of the Zero's is no big deal I think. But we need to be sure that that does not raise new problems!

[Author]

Posts