#apache #archlinux #asterisk #centos #debian #gentoo #haskell #kde #kubuntu #lisp #math #mysql #perl #python #ruby-lang #rubyonrails #suse #ubuntu #vim #wikipedia 0 1 2 3 4 5 6 7 8 9 10 11 12 13
Top Prev 5413 5414 5415 5416 5417 5418 5419 5420 5421 5422 5423 5424 5425 5426 5427 5428 5429 5430 5431 Next
#mysql
<mindeq> yeah this i think is the irght one
<mindeq> d;-)
<snoyes> Anybody up for a little challenge? Explain to me this behavior: http://hashmysql.org/paste/6385
<nils_> snoyes, enum again?
<snoyes> Yes, but why does it go back and forth?
<nils_> only two values in it, 3 and 4?
<snoyes> http://hashmysql.org/paste/6386 there's the create table
<Xgc> snoyes: Is this a trick question? You have a trigger?
<snoyes> no triggers.
<snoyes> No tricks.
<Xgc> Ah. I wouldn't depend on behavior of that type of calculation.
<nils_> wait this is strange.
<snoyes> I'm not going to depend on it. I just want to know why it goes back to 3.
<Xgc> snoyes: Is that supposed to be well defined?
<nils_> create table stumper (thedata enum('3', '4') not null); will give me a warning when inserting a 3
<Xgc> snoyes: It's probably assuming integral positions and there are none. The order may be undefined.
<nils_> it's always going back and forth, also the INT value!
<nils_> when theData is 4, the integer value is 2.
<nils_> when 3 it's three
<Xgc> The int value is probably taken as a position in the set, which probably isn't guaranteed.
<crzygrndpa> Can someone take a look at these two queries? http://pastie.caboo.se/41396 the first works fine but when I try to count the results of the first I get: duplicate column 'id' I know that the problem is with the second JOIN but if I try to reference the alias from the first JOIN I get: duplicate alias... any thoughts?
<crzygrndpa> I mean Not unique table/alias: 'media'
<nils_> snoyes, try that: update stumper set thedata = cast(thedata as signed integer) + 1; SELECT * FROM stumper;
<snoyes> nils_: that gives me 3, then 2, then 1, and 1 forever.
<nils_> snoyes, yes, it cycles at least.
<snoyes> er, acutally a data truncated error after 1.
<snoyes> So what I want to know, is how come from 3 to 4 it uses the value, and from 4 to 3 it uses the index?
<nils_> index starting with zero?
<snoyes> yes
<Xgc> snoyes: Coincidence that the value matches the index in some cases.
<nils_> so 4 is the last index...
<snoyes> Xgc: but if it always uses the index, 3 + 1 would be 2
<Xgc> snoyes: I'm guessing the position/index changes based on the SQL.
<snoyes> but the sql was the same in each case
<DavidHKMrPowers> CareBear\, any idea?
<CareBear\> David : I say represent one logical operation or one type of object with one table. This would fall under one logical operation. If it's possible to update both tel and fax at the same time I would use the table you suggested.
<DavidHKMrPowers> CareBear\, the user may just modify his tel
<DavidHKMrPowers> but sometimes, he may modify both at the same time
<CareBear\> David : Yep. I think your table is good.
<DavidHKMrPowers> CareBear\, so that sometimes, the fax or the tel field will be left blank?
<Niacin> sigh i foobared this replication
<CareBear\> David : I would use NULL to indicate "no change" - after all, the user could simply remove his fax number because he sold the fax machine, then the field should be blank.
<DavidHKMrPowers> CareBear\, thanks :D
<CareBear\> David : You're welcome.
<poncha> why cant i use variables in grant statement ? (i want user and password to be configurable options in the beginning of sql script and then used by grant later
<poncha> grant select,insert,update on foo.* to @user@'localhost' ... results in syntax error near '@user ..
<CareBear\> poncha : 'username'@'localhost'
<poncha> CareBear\, thats exactly what i dont want...
<CareBear\> poncha : Oh, why, no..
<CareBear\> poncha : That's the only way it works..
Previous Page Next Page