/ Forside / Teknologi / Udvikling / SQL / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
SQL
#NavnPoint
pmbruun 1704
niller 962
fehaar 730
Interkril.. 701
ellebye 510
pawel 510
rpje 405
pete 350
gibson 320
10  smorch 260
MSSQL "4a" -> int 4
Fra : Leif Neland


Dato : 06-02-07 11:07

Findes der en måde i MsSql at konvertere som meget som muligt af en streng
til et tal, uden at få en fejl.

Så "34 heste" bliver til tallet 34

"3-4" til tallet 3

Leif




 
 
Peter Brodersen (06-02-2007)
Kommentar
Fra : Peter Brodersen


Dato : 06-02-07 11:20

On Tue, 6 Feb 2007 11:06:48 +0100, "Leif Neland" <leif@neland.dk>
wrote:

>Findes der en måde i MsSql at konvertere som meget som muligt af en streng
>til et tal, uden at få en fejl.

En hurtig metode:
streng + 0

>Så "34 heste" bliver til tallet 34

For eksempel:
SELECT "34 heste" + 0

Det giver dog en forventet warning (Truncated incorrect DOUBLE value:
'34 heste'), men ingen fejl.

Alternativt kan du kigge på CAST, som er standard SQL:

SELECT CAST("34 heste" AS DECIMAL)

SELECT CAST("34 heste" AS UNSIGNED)

SELECT CAST("34 heste" AS SIGNED)

--
- Peter Brodersen
Kendt fra Internet

Jens Gyldenkærne Cla~ (06-02-2007)
Kommentar
Fra : Jens Gyldenkærne Cla~


Dato : 06-02-07 11:30

Peter Brodersen skrev:

>> Findes der en måde i MsSql at konvertere som meget som muligt
>> af en streng til et tal, uden at få en fejl.
>
> En hurtig metode:
> streng + 0

Jeg gætter på at du har læst y i stedet for s (MSSQL <> MySQL).

De metoder du viser giver fejl i MSSQL.
--
Bolig søges. Andel eller leje i Emdrup, Nordvest, Nørrebro, Søborg
eller Brønshøj, max 6000 pr. måned.
Kontakt pr. mail - nospam(at)gyros.dk
Jens Gyldenkærne Clausen

Peter Brodersen (06-02-2007)
Kommentar
Fra : Peter Brodersen


Dato : 06-02-07 11:41

On Tue, 06 Feb 2007 11:30:22 +0100, Jens Gyldenkærne Clausen
<jens@gyros.invalid> wrote:

>Jeg gætter på at du har læst y i stedet for s (MSSQL <> MySQL).

Ahja - sådan går det, når man er for hurtig.

>De metoder du viser giver fejl i MSSQL.

Hm - den CAST-syntaks er ellers en del af SQL92.

Indsæt valgfri joke om at MySQL understøtter den

--
- Peter Brodersen
Kendt fra Internet

Leif Neland (06-02-2007)
Kommentar
Fra : Leif Neland


Dato : 06-02-07 11:40


"Peter Brodersen" <usenet2007@ter.dk> skrev i en meddelelse
news:eq9krc$np0$1@news.klen.dk...
> On Tue, 6 Feb 2007 11:06:48 +0100, "Leif Neland" <leif@neland.dk>
> wrote:
>
> >Findes der en måde i MsSql at konvertere som meget som muligt af en
streng
> >til et tal, uden at få en fejl.
>
> En hurtig metode:
> streng + 0
...
> Alternativt kan du kigge på CAST, som er standard SQL:
>
> SELECT CAST("34 heste" AS DECIMAL)
...
Nej, det fungerer ikke. Uanset hvad jeg prøver, om det er cast, convert
eller "34 heste" + 0 får jeg fejlen:
"Error converting '34 heste' to int"

MsSql mangler TO_NUMBER:

"The following two examples show how TO_NUMBER converts a string to a
number: removing leading and trailing zeros, resolving multiple signs and
removing plus signs, and truncating the number when it encounters a
non-numeric character:"

Det er det med at trunkere, når man når et ikke-ciffer, der mangler.

Leif



Peter Lykkegaard (06-02-2007)
Kommentar
Fra : Peter Lykkegaard


Dato : 06-02-07 21:51

Leif Neland wrote:

> MsSql mangler TO_NUMBER:
>
Men har PatIndex

Prøv at kikke på den her artikel
http://www.databasejournal.com/features/mssql/article.php/3071531

- Peter

--
Hi! I'm a .signature *virus*!
Copy me into your ~/.signature to help me spread!



Jens Gyldenkærne Cla~ (06-02-2007)
Kommentar
Fra : Jens Gyldenkærne Cla~


Dato : 06-02-07 12:34

Peter Brodersen skrev:

>> De metoder du viser giver fejl i MSSQL.
>
> Hm - den CAST-syntaks er ellers en del af SQL92.

CAST virker også fint i MSSQL - så vidt jeg kan se er det MySQL der
ikke holder sig til standarden.

Hvis jeg læser 6.10.3.b i SQL-92 korrekt, skal der kastes en
undtagelse hvis en streng, efter at den er trimmet for indledende
og afsluttende mellemrum, ikke kan læses som en "signed numeric
literal". Det er netop hvad MSSQL gør (jeg er ikke helt sikker på
om håndteringen af mellemrum mellem <sign> og <unsigned numeric
literal> er korrekt, men andre tekststrenge kaster en undtagelse
som de skal).


De følgende casts fungerer alle i MSSQL:

SELECT CAST('3' AS integer)
SELECT CAST(' 3 ' AS integer)
SELECT CAST(' -3' AS integer)
SELECT CAST(' - 3' AS integer)
SELECT CAST(' - 3 ' AS integer)


Et lille pluk fra SQL-92:


,---- [ 6.10 <cast specification> ]
| 3) If TD is exact numeric, then
|
| Case:
|
|        [snip]
|
| b) If SD is character string, then SV is replaced by SV with any
| leading or trailing <space>s removed.
|
| Case:
|
| i) If SV does not comprise a <signed numeric literal> as
| defined by the rules for <literal> in Subclause 5.3,
| "<literal>", then an exception condition is raised:
|         data exception-invalid character value for cast.
|
`----
<http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt>


> Indsæt valgfri joke om at MySQL understøtter den

Tja - eksemplet er et blandt utallige på at MySQL tillader
konstruktioner der giver fejl i andre databasesystemer (og burde
give fejl i forhold til standarderne).
--
Bolig søges. Andel eller leje i Emdrup, Nordvest, Nørrebro, Søborg
eller Brønshøj, max 6000 pr. måned.
Kontakt pr. mail - nospam(at)gyros.dk
Jens Gyldenkærne Clausen

Leif Neland (06-02-2007)
Kommentar
Fra : Leif Neland


Dato : 06-02-07 15:45


"Jens Gyldenkærne Clausen" <jens@gyros.invalid> skrev i en meddelelse
news:Xns98CF7FE251C8Cjcdmfdk@gyrosmod.dtext.news.tele.dk...

>
> > Indsæt valgfri joke om at MySQL understøtter den
>
> Tja - eksemplet er et blandt utallige på at MySQL tillader
> konstruktioner der giver fejl i andre databasesystemer (og burde
> give fejl i forhold til standarderne).

Men oftest så giver MySQL en fornuftig løsning, i stedet for at
applikationen dør med en fejl:

"4heste" -> 4
32. marts -> 1. april
substring(hest,3,0) -> ""

Så man "slipper" for en del if-then konstruktioner.

Man kan vel ikke sige "on error continue" til MsSql

Leif



Jens Gyldenkærne Cla~ (06-02-2007)
Kommentar
Fra : Jens Gyldenkærne Cla~


Dato : 06-02-07 16:07

Leif Neland skrev:

> Men oftest så giver MySQL en fornuftig løsning, i stedet for
> at applikationen dør med en fejl:
>
> "4heste" -> 4
> 32. marts -> 1. april
> substring(hest,3,0) -> ""

Spørgsmålet er om det er fornuftigt eller ej. Det er da meget
praktisk hvis man bare vil have skidtet til at køre uden for mange
krumspring, men det sker jo på bekostning af datasikkerheden.

Det kan godt være at 4, 1. april og "" er det der blev ment i
ovenstående, men det er ikke nødvendigvis sikkert (specielt er
sidstnævnte konstruktion problematisk i mine øjne - hvis det
betyder at MySQL konverterer et objektnavn til en streng hvis jeg
kommer til at stave det forkert).

MySQL er designet efter en filosofi hvor man i udstrakt grad lader
databasen "gætte" eller "rette" i forespørgsler for at undgå fejl.
Det er ikke en fordel i mine øjne.

Jeg kan godt savne nogle flere funktioner i MSSQL (fx direkte
understøttelse af regex), men jeg er glad for at den hellere fejler
end gætter.
--
Bolig søges. Andel eller leje i Emdrup, Nordvest, Nørrebro, Søborg
eller Brønshøj, max 6000 pr. måned.
Kontakt pr. mail - nospam(at)gyros.dk
Jens Gyldenkærne Clausen

Jens Gyldenkærne Cla~ (06-02-2007)
Kommentar
Fra : Jens Gyldenkærne Cla~


Dato : 06-02-07 11:28

Leif Neland skrev:

> Findes der en måde i MsSql at konvertere som meget som muligt
> af en streng til et tal, uden at få en fejl.

Hvilken version af MSSQL?

Hvis det er 2005, kan du benytte dig er CLR-integration og få .NET
til at håndtere strengen, fx via et regex:

<http://blogs.msdn.com/sqlclr/archive/2005/06/29/regex.aspx>

I 2000 kan du måske bruge følgende xp:

<http://www.codeproject.com/managedcpp/xpregex.asp>


Begge dele er utestet.
--
Bolig søges. Andel eller leje i Emdrup, Nordvest, Nørrebro, Søborg
eller Brønshøj, max 6000 pr. måned.
Kontakt pr. mail - nospam(at)gyros.dk
Jens Gyldenkærne Clausen

Søg
Reklame
Statistik
Spørgsmål : 177579
Tips : 31968
Nyheder : 719565
Indlæg : 6409073
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste