Sådan løses 'Konvertering mislykkedes, når der konverteres dato og / eller tid fra tegnstreng' Fejl?

Der er mange tilfælde, hvor datoer og tidspunkter ikke vises i det format, du vil have det, og en forespørgseloutput passer heller ikke til seernes behov. Der er flere SQL Servers indbyggede funktioner til at formatere datostrengen efter dit behov, men for strengen skal fortolkes af SQL Server og for at undgå konverteringsfejl skal den være i et korrekt format. Når vi forsøger at konvertere dato eller tid fra tegnstreng, opstår der nogle gange følgende fejl. "Konvertering mislykkedes ved konvertering af dato og / eller tid fra tegnstreng."

Den ovennævnte fejl opstår normalt, når den bogstavelige dato ikke er korrekt og ikke kan konverteres fra strengen til DateTime eller date. Denne fejl skyldes en række årsager, som vi vil diskutere detaljeret sammen med løsningssættet.

Eksempel 1:

Storbritannien Dato og klokkeslæt viser datoen ved hjælp af formatet dag-måned-år (10. januar 2015 eller 10/1/2015), som vi kan opnå ved hjælp af SQL Server-indbygget-funktion “konvertere” -funktion med formatering 103.

Her i eksemplet nedenfor kan vi se, at den angivne datostreng er i det forkerte format. For det første giver det måneden, derefter dage og sidste år, som er forkert og ikke kan fortolkes af SQL Server, hvilket resulterer i en fejl. Det korrekte format til konvertering af britisk typedato ved hjælp af "103" datoformat er "dd / mm / åååå".

Forkert format:

Erklær @date_time_value varchar (100) = '10 / 16/2015 21:02:04 'vælg CONVERT (datetime2, @date_time_value, 103) som UK_Date_Time_Style

Korrekt format:

Det britiske og franske datoformat er 103 = "dd / mm / åååå" eller 3 = "dd / mm / åå". Her er 103 og 3 datoformater.

Erklær @date_time_value varchar (100) = '10 / 1/15 21:02:04 'vælg CONVERT (datetime2, @date_time_value, 103) som Date_Time_Style

Erklær @date_time_value varchar (100) = '10 / 1/15 21:02:04 'vælg CONVERT (datetime2, @date_time_value, 3) som UK_Date_Time_Style

Eksempel 2:

Undertiden resulterer konvertering af streng til dato i SQL-server i fejl, ikke på grund af de anvendte dato- eller tidsformater, snarere er det fordi du forsøger at gemme forkerte oplysninger, der ikke kan accepteres af ordningen.

Forkert dato:

Årsagen til den følgende fejl er kun, at der i år 2019 ikke findes nogen dato som “29. februar”, fordi det ikke er et skudår.

Erklær @date_time_value varchar (100) = '2019-02-29 21:02:04' vælg rollebesætning (@date_time_value som datetime2) som date_time_value

Korrekt en:

Erklær @date_time_value varchar (100) = '2019-02-28 21:02:04' vælg rollebesætning (@date_time_value som datetime2) som date_time_value

ISO 8601 Datoformat:

Selvom der findes adskillige formater til manipulation af datoværdier, kan det være et brugervenligt problem at vælge en datetime-repræsentation, når man arbejder for en global / international masse. Så kulturspecifikke dato- / tidslitteratur bør undgås. Hvis vi betragter denne dato som "03/08/2018", fortolkes den på forskellige måder i forskellige regioner i verden.

I britisk stil fortolkes det som "8. marts 2018"
I europæisk stil fortolkes det som "3. august 2018"

Heldigvis er der et alternativ i det internationale datoformat udviklet af ISO. Den globale standard ISO 8601-format “ÅÅÅÅ-MM-DDThh: mm: ss” er en mere sproguafhængig mulighed for strengbogstaver, og den løser alle disse problemer. Mens "åååå" er året, er "mm" måned og "dd" er dag. Så datoen "8. marts 2018" i internationalt ISO-format er skrevet som "2018-03-08". Således er ISO-format det bedste valg til datorepræsentation.

Erklær @date_time_value varchar (100) = '2019-03-28 21:02:04' vælg konverter (datetime2, @ date_time_value, 126) som [åååå-mm-ddThh: mi: ss.mmm]

Anbefalinger:

Forhåbentlig hjælper denne artikel med at lindre den forvirring, jeg ofte har set i samfundet om dato- / tidsværdier. Det anbefales dog aldrig at gemme datoer i teksttype (varchar, char, nvarchar, nchar eller tekst) Altid gemme datoværdi i kolonner DATE, DATETIME og helst DATETIME2 (giver mere præcision) og efterlade formateringen af datoinformationen til brugergrænsefladeslaget i stedet for at blive hentet fra databasen.