Il miglior approccio per avere formati datetime coerenti tra SQL Server e VB.Net

Question

Sto sviluppando un'applicazione VB.Net che ha operazioni che dipendono fortemente dalle date & volte. Poiché potrebbero esserci conflitti sui formati di data se il formato della data dell'applicazione non corrisponde al formato della data del server, qual è la procedura migliore per risolvere questo problema. So che il formato di SQL Server datetime dipende dalla lingua del server & VB.Net utilizzerà il formato data/ora locale della macchina. Ciò significa che se un utente modifica il formato datetime causerà problemi durante l'inserimento.

La mia idea è quella di utilizzare SELECT GETDATE() all'avvio dell'applicazione, quindi identificare il suo formato datetime usando VB.Net & ogni volta che provo ad inserire un valore datetime io convertirlo nel formato datetime identificato all'avvio dell'applicazione.

Esiste un approccio migliore per disporre di formati di data/ora coerenti tra l'applicazione & SQL Server per evitare problemi. ad esempio: miscelazione di un giorno con un mese.

Answer 1

SQL Server non memorizza un DateTime in alcun formato di stringa: è memorizzato come valore numerico a 8 byte.

Le varie impostazioni (lingua, formato data) influenzano solo come il DateTime viene mostrato a voi in SQL Server Management Studio - o come viene analizzato quando si tenta di convertire una stringa in un DateTime.

Esistono molti formati supportati da SQL Server: vedere lo MSDN Books Online on CAST and CONVERT. La maggior parte di questi formati è dipendente da in base alle impostazioni in uso; pertanto, queste impostazioni potrebbero funzionare alcune volte, a volte no.

Quindi, se possibile, non convertire date tra DateTime e stringa tutto il tempo! Lasciare come DateTime in .NET, utilizzare DATE o DATETIME2(n) in SQL Server e lasciare che le date siano nel loro formato nativo. Utilizzare le query parametrizzate che supportano il tipo di dati nativo DateTime in modo che non sia necessario per convertire le date in stringa e viceversa!

Se è necessario utilizzare stringhe per rappresentare le date per qualsiasi motivo, l'unico modo affidabile per risolvere questo è quello di utilizzare il (leggermente adattato) ISO-8601 formato data che è supportato da SQL Server - questo formato funziona sempre - indipendentemente dalla lingua di SQL Server e dalle impostazioni di dataformat.

Il ISO-8601 format è supportato da SQL Server è disponibile in due versioni:

• YYYYMMDD per soli Date (senza porzione di tempo); nota qui: senza trattini!, è molto importante! YYYY-MM-DD è NON indipendente dalle impostazioni dateformat nel server SQL e sarà NON funziona in tutte le situazioni!

o:

• YYYY-MM-DDTHH:MM:SS per date e orari - notare qui: questo formato ha trattini (ma può essere omesso), ed una fissa T come delimitatore tra la data e l'ora parte del tuo DATETIME.

Questo è valido per SQL Server 2000 e versioni successive.

Se si utilizza SQL Server 2008 o più recente e il DATE tipo di dati (solo DATE -! nonDATETIME), allora si può davvero utilizzare anche il formato YYYY-MM-DD e che funziona, anche, con tutte le impostazioni in SQL Server .

Non chiedermi perché tutto questo argomento è così complicato e un po 'confuso - è proprio così. Ma con il formato YYYYMMDD, si dovrebbe andare bene per qualsiasi versione di SQL Server e per qualsiasi impostazione di lingua e dateformat in SQL Server.

La raccomandazione per SQL Server 2008 e versioni successive è quella di utilizzare DATE se è necessaria solo la parte relativa alla data e DATETIME2(n) quando sono necessarie sia la data che l'ora. Dovresti provare a eliminare gradualmente il tipo di dati DATETIME, se possibile,