Problém s MYSQL

[Ondrej Koala Vacha]

On Thu, 10 Oct 2002, Karel Zak wrote:

> On Thu, Oct 10, 2002 at 02:13:15PM +0200, Ondrej Koala Vacha wrote:
> > pozice mate definovanou jako tinyint(4), coz je integer cislo v rozsahu 
> > 0-127. Jako integer jsou i dalsi sloupce LOCK_USER_ID a TYP_INDEX, kam 
> > ovsem davate retezcove konstanty. Pak musi probehnout konverze (tusim ze 
> > dle manualu ala perl), ale pokud nevite co delate, tak se o konverzi 
> > nepokousejte a zadavejte ciselne hodnoty.
> 
>  To mate pravdu, ale jak to vysvetluje vyse popsane chovani MySQL?

Mate pravdu nijak, jen jsem ten uplne zmateny priklad jaksi nedocetl az do 
konce. Jestlize se to tinyint cpe retezec, ale ciselny, pak je-li z 
rozsahu se tam da odpovidajici cislo. Pokud je cislo vetsi neb mensi -- 
pak prislusna  hranice. Jestlize by se tam dat retezec z necisel, pak mysql zahlasi 
chybu.
Potud si myslim ze je to konverze ala perl a ma smysl diskutovat jestli ma 
byt nebo ne. Ale kdyz ano, tak je logicka.

> > > Jenže mysql asi obsahuje chybu nebo nevím ... protože sloupec CASOD  coz je
> > > timestamp se změní taky i když s výše uvedenou query nemá naprosto nic
> > > společného, tedy kromě toho že je ve stejné tabulce.
> > > Konkrétně mě změnil sloupec CASOD na 20021010132035, zajimavé, že CASDO
> > > zůstal nezměněn.

Sloupec CASOD je holt timestamp a ten se meni, kdyz probehne update vety,
a ten probehl. Proc se nenastavi i druhy timestamp bych musl vyzkouset 
nebo najit, ale celkem by me neprekvapilo, kdyby tam mohl byt jen jeden platny 
(nastavovany), protoze mit tam vic jak 1 je celkem nanic.

-- 
Ondrej Koala Vacha