Ekko Skrevet 3. februar 2007 Del Skrevet 3. februar 2007 (endret) Hei Har et problem med en mysql-insertkommando. Den endrer verdiene i en kolonne i tabellen jeg ikke ber den endre. I kodesnutten under ser man følgende: -Jeg har en tabell hvor noen av oppføringene på i kolonnen "fri" er 480. -Jeg kjører så en insert på kolonnen "fravær" -Etter dette blir alle verdiene i kolonnen "fri" satt til 0 -Til slutt følge en desc av tabellen. Hvorfor blir 480 til 0? mysql> select ansattnr, dato, fri, fravaer from temptimeliste; +----------+------------+------+---------+ | ansattnr | dato | fri | fravaer | +----------+------------+------+---------+ | 27 | 2006-07-25 | NULL | NULL | | 27 | 2006-07-26 | NULL | NULL | | 27 | 2006-07-27 | NULL | NULL | | 27 | 2006-07-28 | NULL | NULL | | 27 | 2006-08-14 | NULL | NULL | | 27 | 2006-08-15 | NULL | NULL | | 27 | 2006-08-16 | NULL | NULL | | 27 | 2006-08-17 | NULL | NULL | | 27 | 2006-08-18 | NULL | NULL | | 27 | 2006-08-21 | NULL | NULL | | 27 | 2006-08-22 | NULL | NULL | | 27 | 2006-08-23 | NULL | NULL | | 27 | 2006-08-24 | NULL | NULL | | 27 | 2006-08-25 | NULL | NULL | | 27 | 2006-08-28 | NULL | NULL | | 27 | 2006-08-29 | NULL | NULL | | 27 | 2006-08-30 | NULL | NULL | | 27 | 2006-08-31 | NULL | NULL | | 27 | 2006-09-01 | NULL | NULL | | 27 | 2006-08-01 | 480 | NULL | | 27 | 2006-08-02 | 480 | NULL | | 27 | 2006-08-03 | 480 | NULL | | 27 | 2006-08-04 | 480 | NULL | | 27 | 2006-08-07 | 480 | NULL | | 27 | 2006-08-08 | 480 | NULL | | 27 | 2006-08-09 | 480 | NULL | | 27 | 2006-08-10 | 480 | NULL | | 27 | 2006-08-11 | 480 | NULL | +----------+------------+------+---------+ 28 rows in set (0.00 sec) mysql> INSERT INTO temptimeliste (ansattnr, dato, fravaer) VALUES(27, '2006-10-31', 480); Query OK, 1 row affected (0.00 sec) mysql> select ansattnr, dato, fri, fravaer from temptimeliste; +----------+------------+------+---------+ | ansattnr | dato | fri | fravaer | +----------+------------+------+---------+ | 27 | 2006-07-25 | NULL | NULL | | 27 | 2006-07-26 | NULL | NULL | | 27 | 2006-07-27 | NULL | NULL | | 27 | 2006-07-28 | NULL | NULL | | 27 | 2006-08-14 | NULL | NULL | | 27 | 2006-08-15 | NULL | NULL | | 27 | 2006-08-16 | NULL | NULL | | 27 | 2006-08-17 | NULL | NULL | | 27 | 2006-08-18 | NULL | NULL | | 27 | 2006-08-21 | NULL | NULL | | 27 | 2006-08-22 | NULL | NULL | | 27 | 2006-08-23 | NULL | NULL | | 27 | 2006-08-24 | NULL | NULL | | 27 | 2006-08-25 | NULL | NULL | | 27 | 2006-08-28 | NULL | NULL | | 27 | 2006-08-29 | NULL | NULL | | 27 | 2006-08-30 | NULL | NULL | | 27 | 2006-08-31 | NULL | NULL | | 27 | 2006-09-01 | NULL | NULL | | 27 | 2006-08-01 | 0 | NULL | | 27 | 2006-08-02 | 0 | NULL | | 27 | 2006-08-03 | 0 | NULL | | 27 | 2006-08-04 | 0 | NULL | | 27 | 2006-08-07 | 0 | NULL | | 27 | 2006-08-08 | 0 | NULL | | 27 | 2006-08-09 | 0 | NULL | | 27 | 2006-08-10 | 0 | NULL | | 27 | 2006-08-11 | 0 | NULL | | 27 | 2006-10-31 | NULL | 480 | +----------+------------+------+---------+ 29 rows in set (0.00 sec) mysql> desc temptimeliste; +---------------+------------+------+-----+------------+-------+ | Field | Type | Null | Key | Default | Extra | +---------------+------------+------+-----+------------+-------+ | Ansattnr | int(11) | NO | PRI | 0 | | | dato | date | NO | PRI | 0000-00-00 | | | totmin | int(11) | YES | | NULL | | | minetter13 | int(11) | YES | | NULL | | | minetter16 | int(11) | YES | | NULL | | | minetter23 | int(11) | YES | | NULL | | | ordtimer | float | YES | | NULL | | | lunsj | float | YES | | NULL | | | helgetillegg | float | YES | | NULL | | | kveldstillegg | float | YES | | NULL | | | femti | float | YES | | NULL | | | hundre | float | YES | | NULL | | | helg | tinyint(1) | YES | | NULL | | | uke | int(11) | YES | | NULL | | | lunch | int(11) | YES | | NULL | | | fri | float | YES | | NULL | | | fravaer | float | YES | | NULL | | +---------------+------------+------+-----+------------+-------+ 17 rows in set (0.02 sec) mysql> Endret 3. februar 2007 av Ekko Lenke til kommentar
roac Skrevet 3. februar 2007 Del Skrevet 3. februar 2007 Det ser ikke logisk ut for meg. Jeg vet ikke om du selv har laget hele løsningen, hvis ikke ville jeg tippe på at det var en trigger som fyrer av og gjør galskapen, for din insert-kommando returnerer at en rad er påvirket (den ene du satte inn). Lenke til kommentar
Ekko Skrevet 3. februar 2007 Forfatter Del Skrevet 3. februar 2007 Jeg har laget ting selv, finnes ingen triggers og det som står i koden er klipp og lim fra kommandovinduet. Jeg har nå prøvd det samme på en annen maskin, der ser det ut til å fungere slik det skal gjøre. Må være noe merkelig med den innstallasjonen som jeg har prøvd det på først her, kan ikke skjønne annet, så vi får si at problemet er løst. Lenke til kommentar
roac Skrevet 3. februar 2007 Del Skrevet 3. februar 2007 Jeg blir litt nysgjerrig: Hvilken versjon av MySQL er det som går på PCen som har dette problemet? Lenke til kommentar
Ueland Skrevet 3. februar 2007 Del Skrevet 3. februar 2007 Er en viss fare for at du har (i mine øyne) surret med primærnøkler. Med en gang du setter inn noe fra samme medarbeiderID 2 ganger for samme dato vil du få en null, for det er umulig siden du har satt opp primærnøkler for de 2 feltene. En god praksis er å ha et "id" felt med auto increment, så får du hvertfall en feilkilde mindre sånt sett. (samt å skrive SELECT, FROM, ORDER BY osv med store bokstaver for lesbarhet ) Mulig dette har en sammenheng med MySQL-versjonen som roac her er inne på. Lenke til kommentar
roac Skrevet 3. februar 2007 Del Skrevet 3. februar 2007 En god praksis er å ha et "id" felt med auto increment, så får du hvertfall en feilkilde mindre sånt sett. 7865049[/snapback] Nå, hvorvidt surrogatnøkler er løsningen kan jo diskuteres. I dette tilfellet har vi jo tydeligvis da at kombinasjonen av ansatt og dato skal være unik, så løsnignen din (med surrogatnøkkel) vil da medføre at du må ha to unique constraints/indexes, i steden for bare én, noe som i mine øyne ikke umiddelbart er fordelaktig. Dersom det hadde vært fremmednøkler mot denne tabellen så hadde situasjonen stilt seg annerledes, men akkurat her ser det i mine øyne ut som om Ekko har valgt den mest fornuftige, nemlig en sammensatt nøkkel. Når det gjelder valg av datatyper så er nok situasjonen en annen, da det med fordel kunne vært brukt smallint(4) i steden for int en rekkesteder Lenke til kommentar
Ekko Skrevet 3. februar 2007 Forfatter Del Skrevet 3. februar 2007 Er en viss fare for at du har (i mine øyne) surret med primærnøkler. Med en gang du setter inn noe fra samme medarbeiderID 2 ganger for samme dato vil du få en null, for det er umulig siden du har satt opp primærnøkler for de 2 feltene. En god praksis er å ha et "id" felt med auto increment, så får du hvertfall en feilkilde mindre sånt sett. (samt å skrive SELECT, FROM, ORDER BY osv med store bokstaver for lesbarhet ) Mulig dette har en sammenheng med MySQL-versjonen som roac her er inne på. 7865049[/snapback] Insertsetningen har egentlig et "on duplicate key update"-ledd på slutten i programmet mitt, men jeg fjernet dette for demonstarsjons skyld for å gjøre setningen enklere og for å fjerne en feilkilde (dvs at situasjonen oppstår både med og uten dette ekstra leddet). (I prgrammet mitt har jeg ting med store bokstaver, men her gikk det litt fort isvingene) Lenke til kommentar
Ekko Skrevet 3. februar 2007 Forfatter Del Skrevet 3. februar 2007 Jeg blir litt nysgjerrig: Hvilken versjon av MySQL er det som går på PCen som har dette problemet? 7864995[/snapback] 5.0.15 Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå