SQL Server 2005 vs. ASP.net confusione del formato datetime

Question

Ho trovato una domanda simile sullo overflow dello stack, ma in realtà non ha risposto alla domanda che ho. Devo assicurarmi che la mia applicazione asp.net stia formattando la data gg / mm / aaaa come il mio SQL Server 2005.

Come posso verificare se la cultura della data (se è così che si chiama) del server corrisponde a come ho programmato la mia app? Esistono impostazioni specifiche del database e del sistema operativo? È specifico per la tabella? Non voglio trasporre i miei giorni e i miei mesi.

grazie

Answer 1

Quando si estrae un DateTime dal database, dovrebbe essere in un formato non coltivato (come l'oggetto DateTime, basato sul numero di tick da una certa data). È solo quando converti quel valore in una stringa che devi preoccuparti della cultura. In questi casi, puoi utilizzare yourDateTimeValue.ToString (" dd / MM / yyyy " ;, CultureInfo.InvariantCulture) per assicurarti che le informazioni vengano visualizzate correttamente.

Answer 2

Credo che se usi SqlParameters ADO.NET si prenderà cura di tutto il resto e non devi preoccuparti. Inoltre, è buono anche per difendersi dagli attacchi SQL Injection! :)

Answer 3

** Attenzione perché le colonne SQL DateTime non sono annullabili e il loro valore minimo è 1/1/1753 mentre .net DateTimes non sono annullabili con valori minimi di 1/1/0001. **

Se stai estraendo dati da una colonna DateTime reale, per impostazione predefinita saranno sempre nello stesso formato standard. Per salvare i dati nella colonna, potresti voler specificare SqlDbType.DateTime nel tuo parametro.

L'ho strappato da http://bytes.com/forum/thread767920.html:

com.Parameters.Add (" @ adate " ;, SqlDbType.DateTime) .Value = DateTime.Now;

Answer 4

Bene, se conservi i campi datetime nel DB non dovresti preoccupartene.

Fintanto che mantieni le date nell'app fortemente tipizzate (variabili DateTime) e invii le date tramite istruzioni preparate con DBParameter / SqlParameter il tuo DB le prenderà così come sono.

Se usi le stringhe per conservare le tue date nel codice, alcuni cast ti assicureranno di inviare i valori giusti:

string sqlCmd = @"SELECT *
   FROM MyTable
   WHERE MyDateField = CONVERT(datetime, '{0}', 101)";

// assuming myDateString is a string with a date in the local format
sqlCmd = string.Format(sqlCmd,
    Convert.ToDateTime(myDateString).ToString("yyyyMMdd"));

(il codice è brutto, ma spero che ottenga il punto)

Answer 5

Come altri hanno già detto, dovresti stare bene per quanto riguarda la memorizzazione culturale dei dati. Quello che consiglierei è di memorizzare tutti i tuoi orari come orario UTC standard. In SQL Server 2005 e versioni precedenti non è possibile archiviare le informazioni sul fuso orario, ma se tutto è archiviato nell'ora universale, si dovrebbe essere OK perché l'ora può essere convertita all'ora locale in seguito.

SQL Server 2008 ha alcuni tipi di dati che sono a conoscenza dei fusi orari e se si utilizza .NET 3.5 ci sono strumenti per aiutare con la gestione / conversioni del fuso orario.

Sicuramente tieni i tempi in formato universale. Questo farà la differenza se devi lavorare in più fusi orari.