sql >> Databasteknik >  >> RDS >> Sqlserver

Hur bestämmer SQL Server format för implicit datetime-konvertering?

Detta kan bero på en mängd olika faktorer - operativsystemets regionala inställningar, den aktuella användarens språk och datumformatinställningar. Som standard använder Windows US English , och användarens inställningar är US English och MDY .

Men här är några exempel för att visa hur detta kan förändras.

Användaren använder BRITISH språkinställningar:

-- works:
SET LANGUAGE BRITISH;
SELECT CONVERT(DATETIME, '30-04-2012 19:01:45');

-- fails:
SELECT CONVERT(DATETIME, '04/13/2012');
GO

(Fel)

Användaren använder Français:

-- works:
SET LANGUAGE FRENCH;
SELECT CONVERT(DATETIME, '30-04-2012 19:01:45');

-- fails:
SELECT CONVERT(DATETIME, '04/13/2012');
GO

(Fel)

Användaren använder igen Français:

SET LANGUAGE FRENCH;

-- fails (proving that, contrary to popular belief, YYYY-MM-DD is not always safe):
SELECT CONVERT(DATETIME, '2012-04-30');
GO

(Fel)

Användaren använder DMY istället för MDY:

SET LANGUAGE ENGLISH;
SET DATEFORMAT DMY;

-- works:
SELECT CONVERT(DATETIME, '30-04-2012 19:01:45');

-- fails:
SELECT CONVERT(DATETIME, '04-30-2012');
GO

(Fel)

Din bästa insats är alltid att använda ISO-standard, icke-regionala, säkra, entydiga datumformat. De två jag vanligtvis rekommenderar är:

YYYYMMDD                  - for date only.
YYYY-MM-DDTHH:MM:SS[.mmm] - for date + time, and yes that T is important.

Inget av dessa misslyckas:

SET DATEFORMAT MDY;
SET LANGUAGE ENGLISH;
SELECT CONVERT(DATETIME, '20120430');
SELECT CONVERT(DATETIME, '2012-04-30T19:01:45');
SET LANGUAGE FRENCH;
SELECT CONVERT(DATETIME, '20120430');
SELECT CONVERT(DATETIME, '2012-04-30T19:01:45');
SET LANGUAGE BRITISH;
SELECT CONVERT(DATETIME, '20120430');
SELECT CONVERT(DATETIME, '2012-04-30T19:01:45');
SET DATEFORMAT DMY;
SELECT CONVERT(DATETIME, '20120430');
SELECT CONVERT(DATETIME, '2012-04-30T19:01:45');

Därför rekommenderar jag starkt att istället för att låta användare skriva i fritextdatumformat (eller att du själv använder opålitliga format), kontrollera dina inmatningssträngar och se till att de följer något av dessa säkra format. Då spelar det ingen roll vilka inställningar användaren har eller vilka de underliggande regionala inställningarna är, dina datum kommer alltid att tolkas som de datum de var tänkta att vara. Om du för närvarande låter användare ange datum i ett textfält på ett formulär, sluta göra det och implementera en kalenderkontroll eller åtminstone en vallista så att du i slutändan kan styra strängformatet som skickas tillbaka till SQL Server.

För lite bakgrund, läs Tibor Karaszis "The ultimate guide to the datetime" datatyper" och mitt inlägg "Dåligt Vanor att sparka :Felhantering av datum-/intervallfrågor."



  1. EXPORTERA SOM INFOGA UTTALANDE:Men i SQL Plus åsidosätter raden 2500 tecken!

  2. Nätverksadaptern kunde inte upprätta anslutningen vid anslutning till Oracle DB

  3. Geo-sökning (avstånd) i PHP/MySQL (prestanda)

  4. ListView Control Drag Drop Events Hantering