Fejl ved konvertering

hvorfor er en kolone der skal indeholde tal, sat op som varchar ?

misforstår jeg noget?

Det er fordi den er oprindelig importeret fra en kommasepareret tekstfil, og dem der har lavet i importprogrammet har åbenbart ikke gjort sig den umage at konveret det. Så må jeg gøre det på bagkant...

nu ved jeg ikke om du har mulighed for at scripte lidt asp, for der har jeg et script der kan undesøge om en given record er tal eller ej. så er det jo bare at lave en løkke :)

Det var selvf en mulighed - men jeg var mere lun på ideen om jeg kunne få SQL serveren til at spytte ud med hvilke(n) record(s) der fejler...

jeg sad netop og kikkede på den mulighed, men jeg kan ikke umeldbart se en function der gør det

Kunne du ikke overveje at konvertere hele kolonnen til decimal?

alter table captura modify amount decimal(19,2);

tjo, men så vil han jo også miste værdier, hvis der er nogle non-integer rækker blandt de 82.000

angak> Server: Msg 170, Level 15, State 1, Line 1
Line 1: Incorrect syntax near 'amount'.

?

fixxer> Ja - jeg ville hellere finde dem...

select *
from captura
where IsNumeric(Amount) = 0

jeg er netop igang med et lille script, som du kan køre remote fra mig af, og så får du vist en liste med de felter den er gal med...

Alter table captur
alter column Amount decimal(19,2)

tror sørmer benny.tordrup kom med svaret der :)

Benny - tak :-)

Du skal bare ikke ponke mig med en hammer, hvis den returnerer mere end 5000 poster :-)

Benny.. Nææh.. Jeg fik 19 poster i alt. Det er nogen gamle records nok fra da man startede på at indlæse filen hvor man havde fået en "smule" med fra feltet ved siden af beløbsfeltet i tekstfilen.

Nå, men jeg har lige spurgt dem der udvikler systemet om det ikke var en ide at konvertere nummerics allerede ved indlæsning af filen så vi ikke skal bruge databasetid på at konveretere det hele tiden... Og så undgik man også sådan noget pjat som det her :-)

IMO kan der fanges en del i forbindelse med designet af databasen. Brug en datatype, der er fornuftig til formålet - i forbindelse med beløbsfelter vil jeg baseret på egen erfaring anbefale decimal(19,2) eller decimal(19,4) alt efter temparament.

Felter til valutakurs vil jeg anbefale decimal(x, 4) eller decimal(x, 6)

Ved at bruge decimal undgår du også mange problemer med afrunding, hvilket er et gevaldigt problem med float/single.

Hvis du har felter, som er 100% afhængig af indholdet af andre felter i tabellen, så overvej kraftigt beregnede felter. Et eksempel er en posts valutaværdi i en stamvaluta ud fra kursen.

Benny - jeps, jeg er enig. Databasen er designet for flere år siden lang tid før jeg overhovedet kendte til den...

Har du noget reference (gerne på nettet) til beregnede felter - hvor jeg kan læse lidt mere om det? Jeg har nemlig noget valutakurs halløj hvor jeg skal konsolidere med en fast kurs...

Uddrag fra Books Online omkring Create table (og for så vidt også alter table)

CREATE TABLE
    [ database_name.[ owner ] . | owner. ] table_name
    ( { < column_definition >
        | column_name AS computed_column_expression
        | < table_constraint > ::= [ CONSTRAINT constraint_name ] }
            | [ { PRIMARY KEY | UNIQUE } [ ,...n ]
    )

Du angiver et beregnet felt med linie column_name as computed_column_expression.

...


computed_column_expression

Is an expression defining the value of a computed column. A computed column is a virtual column not physically stored in the table. It is computed from an expression using other columns in the same table. For example, a computed column can have the definition: cost AS price * qty. The expression can be a noncomputed column name, constant, function, variable, and any combination of these connected by one or more operators. The expression cannot be a subquery.

Computed columns can be used in select lists, WHERE clauses, ORDER BY clauses, or any other locations in which regular expressions can be used, with the following exceptions:

A computed column cannot be used as a DEFAULT or FOREIGN KEY constraint definition or with a NOT NULL constraint definition. However, a computed column can be used as a key column in an index or as part of any PRIMARY KEY or UNIQUE constraint, if the computed column value is defined by a deterministic expression and the data type of the result is allowed in index columns.
For example, if the table has integer columns a and b, the computed column a+b may be indexed, but computed column a+DATEPART(dd, GETDATE()) cannot be indexed because the value may change in subsequent invocations.

A computed column cannot be the target of an INSERT or UPDATE statement.


Note  Each row in a table can have different values for columns involved in a computed column, therefore the computed column may not have the same value for each row.

The nullability of computed columns is determined automatically by SQL Server based on the expressions used. The result of most expressions is considered nullable even if only non-nullable columns are present because possible underflows or overflows will produce NULL results as well. Use the COLUMNPROPERTY function (AllowsNull property) to investigate the nullability of any computed column in a table. An expression expr that is nullable can be turned into a non-nullable one by specifying ISNULL(check_expression, constant) where the constant is a non-NULL value substituted for any NULL result.


Du kan lave casts for at få returneret i bestemt datatype.

Hvis du har et felt Amount af typen decimal(19,4), et felt Rate af typen decimal(19,6), kan du beregne AmountBase som:

AmountBase as cast(Amount*Rate/100 ad decimal(19,4))