talværdier indsat i mysql

integer eller decimal f.eks.

long

så kan du typecaste det nemt..
en decimal skal convertes.

hos vent.. mysql.. ja så ved jeg ikke om det holder stik;)

tal er sku da vel tal. DOUBLE :p

tak - men når jeg så exporterer til exxel fra mysql - så kommer værdierne ikke ud så talværedier i exxel der kan summeres? hvorfor? Værdierne kommer som var de et tekstfelt i exxel - -  har prøvet med int ect....

det kommer jo an på hvordan du eksporterer det ...  hvilket program bruger du ?

eksporterer fra udbyder one.com til microsoft excel..

windcape >>

lad mig forklare til dig årsagen til mit svar;)

jeg troede vi var i ASP.NET og med MSSQL database.. (spørgsmålet her ligger lige over et ASP.NET spørgsmål.. så tjekkede katagorien og troede vi var i det andet)

men men... du må da gerne prøve at gøre følgende hvis du ikke selv kender til dette!

opret et Decimal felt i MSSQL... og hent det ind via. C# med typecast til double eller int

altså

double eks = (double)reader["felt"];

nej det kan du ikke vel?

men

double eks = Convert.ToDouble(reader["felt"]);

så nej tal er ikke bare tal.

sorry - sad i min egen forståelse af tingene....;-) - arbejder med php...

koder du selv php, eller benytter du phpmyadmin til at eksportere?    forstår ikke helt hvor problemet opstår ..

phpmyadmin - problemet er at når jeg eksporterer til excel så bliver det ikke talværdier der bliver eksporteret - - værdierne bliver eksporteret ind i felter i exel-arket - men ikke som talværdier.... Jeg kan eksempelvis ikke summere værdierne i felterne... tallene i felterne står venstrecentreret, som hvis jeg brugte anførselstegn for at markere at indholdet skal være "tekst"..

INTEGER hvis heltal eller DECIMAL(m,n) hvis ikke heltal er med stor sandsynlighed
den rigtige data type

men alt tyder jo paa at det ikke er data typen som er problemet

Excel genkender ikke tallene i import filen (som jeg antager er CSV) som tal

engelsk punktum versus dansk komma maaske ?

ok jeg kan godt eksportere ved at bruge "csv" til ms excel - så jeg får en række data komme-adskildt. Dem kan jeg så kopiere ind i et excelark - og det virker - men det er da en lidt omstændig proces ??

thorkil

kalp

Det er jo bare fordi asp.net ikke kan typecast direkte til en double? :-) Derudover så burde reader["felt"] jo slet ikke kræve typecast, medmindre du henter alt data ud i strings? :p

thorkil1:

- export til CSV
- åben excel
- vælg "impoter" , csv
- færdig :-)

wincape >>

Jeg tror du tager fejle denne gang.

og nej henter ikke strings via. reader[""]
men jeg synes du skal tage og forsøge det jeg beskrev når du ikke helt kender det;)

og til din kommentar med at asp.net ikke kan typecast direkte til double... det siger du ikke?:)

Kommentar: kalp
26/01-2007 11:34:35

skriver jeg netop at jeg troede vi var i ASP.NET og med MSSQL database.

jeg træk selv ordene tilbage før du kommenterede da jeg så det var en forkert katagori, men det ændre ikke på, at du skal konvertere en decimal til double hvis du arbejder med mssql og asp.net.. og så kan årsagen jo være ligemeget

1000 tak...

det virker som windscape beskriver... tak

giv et svar og jeg sender point ;-) - hvem der nu kom med det endelige svar ........

kalp

Jeg kan stadig ikke forstå hvorfor du ikke kan bruge DOUBLE i din database, og så bruge double i din C# kode også. Begge er normale native types, som gerne skulle være fuldt understøttet.

windcape >>

Nu kommentere jeg lige dit indlæg og så må du lige sige om det er mig som har misforstået noget eller om det er dig som var lidt for hurtig okay?:)

Læs min første kommentar her i tråden.

*********
long

så kan du typecaste det nemt..
en decimal skal convertes.
*********

Hvad misforstår du i denne kommentar? (husk på at den er lagt ud fra at jeg troede vi arbejde med ASP.NET og MSSQL)

1. nej du kan ikke bare skrive double i en MSSQL database da den ikke findes! Derfor skrev jeg long i min kommentar..
2. long kan typecastes til double meget let
3. decimal kan ikke typecastes til en double eller long
4. long kan typecastes nemt til en double

og jeg prøver OVERHOVEDET ikke være eller virke provokerende... men fatter ærligt ikke dine kommentare:S

Jeg har trods alt ikke sagt noget forkert

og kan se jeg selv skriver noget vås.. ikke long men "Float"

nr. 1 :p

Men det sagde du jo aldrig noget om :p

Derudover er nr. 3 lidt slack.. Det burde .NET kunne klare uden problemer, hvis det holder stik så er der dømt endnu en næse til Microsoft.

kalp>

SQLServer har double precision floating point (for at forvirre C# og Java programmører
kalder den den for FLOAT, mens single precision floating point hedder REAL)

der kan konverteres alle veje mellem BIGINT/DECIMAL/FLOAT i SQLServer og alle
veje mellem long/decimal/double i C#

det er faktisk ret sjældent at det er en god ide at have floating point tal
i en database

DECIMAL alias NUMERIC er langt hyppigere det rigtige valg

Jeg ved bare, at der var et system hvor datatypen på nogle kolonner i databasen blev ændret fra Float til Decimal og herefter brokkede C# sig over alle steder i koden hvor der var typecastet på udtrækket fra datareaderen.

(double)reader["etFelt"]

det gik den ikke med til..
en mulighed var så, at skrive Convert.ToDouble istedet og satte mig ikke dybere ind i det da det der skulle løses slet ikke havde noget med dette problem at gøre, men det var en side effekt af de ændringer der var blevet foretaget i databasen.

lukker nu

lukker nu