Hvordan fikser jeg 'Konvertering mislyktes når konvertering av dato og / eller tid fra tegnstreng' feil?
Det er mange tilfeller når datoer og klokkeslett ikke vises i det formatet du vil ha det, og heller ikke en spørreutdata passer til seernes behov. Det er flere SQL Servers innebygde funksjoner for å formatere datostrengen etter ditt behov, men for strengen skal tolkes av SQL Server og for å unngå konverteringsfeil, bør den være i riktig format. Når vi prøver å konvertere dato eller klokkeslett fra tegnstreng, oppstår det noen ganger feil. "Konvertering mislyktes når du konverterte dato og / eller tid fra tegnstreng."
Feilen som er nevnt ovenfor oppstår vanligvis når bokstavelig dato ikke er riktig og ikke kan konverteres fra strengen til DateTime eller date. Denne feilen skyldes flere årsaker, som vi vil diskutere i detalj sammen med løsningssettet.
Eksempel 1:
Storbritannia Dato- og klokkeslettnotering viser datoen ved bruk av formatet dag-måned-år (10. januar 2015 eller 10/1/2015) som vi kan oppnå ved hjelp av SQL Server innebygd funksjon "konvertere" med formateringsstil 103.
Her i eksemplet nedenfor kan vi se at den angitte datostrengen er i feil format. Først er det å gi måned, så dager og i fjor som er galt og ikke kan tolkes av SQL Server, noe som resulterer i en feil. Riktig format for konvertering av britisk stildato ved bruk av “103” dato stil er “dd / mm / åååå”.
Feil format:
Erklær @date_time_value varchar (100) = '10 / 16/2015 21:02:04 'velg CONVERT (datetime2, @date_time_value, 103) som UK_Date_Time_Style
Riktig format:
Det britiske og franske datoformatet er 103 = “dd / mm / åååå” eller 3 = ”dd / mm / åå”. Her er 103 og 3 datostiler.
Deklarer @date_time_value varchar (100) = '10 / 1/15 21:02:04 'velg CONVERT (datetime2, @date_time_value, 103) som Date_Time_Style
Deklarer @date_time_value varchar (100) = '10 / 1/15 21:02:04 'velg CONVERT (datetime2, @date_time_value, 3) som UK_Date_Time_Style
Eksempel 2:
Noen ganger resulterer konvertering av streng til dato i SQL-server i feil, ikke på grunn av dato- eller tidsformatene som brukes, snarere er det fordi du prøver å lagre feil informasjon som ikke er akseptabel for ordningen.
Feil dato:
Årsaken til følgende feil er bare at det i 2019 ikke er noen dato som “29. februar” fordi det ikke er et skuddår.
Deklarer @date_time_value varchar (100) = '2019-02-29 21:02:04' velg rollebesetning (@date_time_value som datetime2) som date_time_value
Riktig en:
Deklarer @date_time_value varchar (100) = '2019-02-28 21:02:04' velg rollebesetning (@date_time_value som datetime2) som date_time_value
ISO 8601 Datoformat:
Selv om mange formater er tilgjengelige for å manipulere datoverdier, kan det være et brukervennlig problem å velge en datetime-representasjon når du arbeider for en global / internasjonal masse. Så kulturspesifikke dato / klokkeslett bør unngås. Hvis vi vurderer denne datoen “03.08.2018”, vil den tolkes på følgende måter i forskjellige regioner i verden.
- I britisk stil tolkes det som "8. mars 2018"
- I europeisk stil tolkes det som "3. august 2018"
Heldigvis er det ett alternativ i det internasjonale datoformatet utviklet av ISO. Den globale standarden ISO 8601-format "ÅÅÅÅ-MM-DDThh: mm: ss" er et mer språkuavhengig alternativ for strenglitteratur og den adresserer alle disse problemene. Mens "åååå" er året, er "mm" måned og "dd" er dag. Så datoen “8. mars 2018” i internasjonalt ISO-format er skrevet som “2018-03-08”. Dermed er ISO-format det beste valget for datorepresentasjon.
Deklarer @date_time_value varchar (100) = '2019-03-28 21:02:04' velg convert (datetime2, @ date_time_value, 126) som [åååå-mm-ddThh: mi: ss.mmm]
Anbefalinger:
Forhåpentligvis vil denne artikkelen være med på å lindre forvirringen jeg ofte har sett i samfunnet om verdier for dato / tid. Det anbefales imidlertid at du aldri lagrer datoer i teksttype (varchar, char, nvarchar, nchar eller text) Alltid lagre datoverdi i kolonnene DATE, DATETIME og helst DATETIME2 (gir mer presisjon) og la datoinformasjonsformateringen til brukergrensesnittlaget i stedet for å bli hentet fra databasen.
