---

Jeg har en textfil indeholdende nogle priser. Denne tekstfil indsætter
jeg i en MySQL-tabel vha. LOAD DATA LOCAL INFILE, og det fungerer
såmænd ganske glimragende.

Mit problem opstår når prisen på en dims er på over tusind kroner,
f.eks. bliver 1.139,00 til 1.13 hvis feltet er decimal(13,2) og 1.14
hvis feltet er float(13,2). Prisen 65,00 bliver fint indsat som
65.00.

Mit første indfald var at det var noget med forskellen på , og . i
talsystemerne, og jeg prøvede derfor at ændre alle forekomster af , i
et tusind tal med . og omvendt, så jeg 1.139,00 blev til 1,139.00, men
det tog MySQL med ophøjet ro, og ændrede ikke opførsel af den grund.

Nuvel, hvis jeg indsætter 1139 i feltet via phpMyadmin, så bliver det
registreret som et tusind et hundrede og ni og tredive - meget fint,
tænkte jeg, og fiksede det sådan at alle poster med en pris på over
tusind blev formateret til eks. 1139. Det har dog heller ikke ændret
en hujende fis i måden MySQL tolker feltet på, det bliver stadig til
1.14 (float(13,2)) eller 1.13 (decimal(13,2)).

Min kode, som jeg kraftigt mistænker for at være fejlagtig kan ses her:

<http://xslt.it-c.dk/~jcv/usenet/tusindfryd.phps>

Forslag modtages naturligvis med kyshånd.

--
| Jonas @ 55.75, 12.42 | <http://verture.net/> |

"Time is an illusion. Lunchtime doubly so."

---

Jonas Voss skrev:

> Mit første indfald var at det var noget med forskellen på , og . i
> talsystemerne, og jeg prøvede derfor at ændre alle forekomster af , i
> et tusind tal med . og omvendt, så jeg 1.139,00 blev til 1,139.00, men
> det tog MySQL med ophøjet ro, og ændrede ikke opførsel af den grund.

Du skal nok fjerne tusinde-seperatoren helt. Det er normalt ikke noget
man bruger, når man "taler" til et program. Mit bud er, at MySQL
fortolker det første . eller , som komma -- derefter stopper den med
at fortolke tallet, så snart den støder på et ulovligt tegn -- dvs.
tegn der ikke er tal.


Venlig hilsen
Jakob

---

In dk.edb.internet.webdesign.serverside.php, Jakob wrote:

> Du skal nok fjerne tusinde-seperatoren helt. Det er normalt ikke noget
> man bruger, når man "taler" til et program. Mit bud er, at MySQL
> fortolker det første . eller , som komma -- derefter stopper den med
> at fortolke tallet, så snart den støder på et ulovligt tegn -- dvs.
> tegn der ikke er tal.

Det var også mit næste indfald, men følgende notationer bliver alle
til 1.14, hvis feltet er float(13,2):

1139,00
1.139
1139
1,139
1139.00
113900
1,139.00
1.139,00

Det kan jeg ikke helt forstå.

--
| Jonas @ 55.75, 12.42 | <http://verture.net/> |

   Fuzzy logic: How we think at 2:00 AM after the bars close.

---

Jonas Voss skrev:

> Det var også mit næste indfald, men følgende notationer bliver alle
> til 1.14, hvis feltet er float(13,2):
>
> 1139,00
> 1.139
> 1139
> 1,139
> 1139.00
> 113900
> 1,139.00
> 1.139,00
>
> Det kan jeg ikke helt forstå.

Prøver jeg med dine tal (MySQL 3.23.54), sker der det, at alt efter
komma ignoreres. Dvs. -- den fortolker kun tal og punktum.

--
Venlig hilsen
Jakob Bock

---

In dk.edb.internet.webdesign.serverside.php, Jakob wrote:

> Prøver jeg med dine tal (MySQL 3.23.54), sker der det, at alt efter
> komma ignoreres. Dvs. -- den fortolker kun tal og punktum.

Ja, det sære er nemlig, at hvis man indsætter det enten via MySQL
direkte, eller via PHPmyAdmin, så går det fint. Men når jeg bruger
LOAD DATA LOCAL INFILE funktionen i MySQL insisterer den på at
formatere tallet 1139 til 1.14, ligemeget hvad jeg gør.

Det er vist på tide at læse lidt op på LOAD DATA inden jeg mister alt
håret på mit hoved.

Tak for hjælpen.

--
| Jonas @ 55.75, 12.42 | <http://verture.net/> |

Ethernet (n): Device used to catch the elusive etherfish.