Sql Server
SQL Server supporta il formato ISO 8601 per la specifica dei valori di data e ora.
L'utilità di utilizzare tale formato è che l'interpretazione della data espressa è indipendente dalla localizzazione (come detto negli articoli precedenti, in cui viene usato il formato ISO yyyymmdd). L'elenco completo dello standard lo si trova qui:
http://www.mcs.vuw.ac.nz/technical/software/SGML/doc/iso8601/ISO8601.html
e da una lettura dello stesso si può dedurre che i pattern yyyymmdd e yyyy-mm-dd dovrebbero essere trattati in modo identico.
Per SQL Server, però, il formato ISO è definito solamente dal seguente pattern:
yyyy-mm-ddThh:mm:ss[.nnn]
Questo significa che pensare che i formati yyyy-mm-dd e yyyymmdd siano identici, quando si parla di SQL...
posted @ sabato 6 maggio 2006 15:03 |
Per sapere con quale account verrano eseguiti gli step di un job è sufficiente avere in mente questi due punti:
1. Lo step è di tipo T-SQL
Se l'owner del job è un account che fa parte del fixed server role sysadmin, allora lo step sarà sempre eseguito utilizzando l'account del servizio Sql Server Agent.
Nel caso in cui l'owner del job non faccia parte del ruolo in questione, lo step verrà sempre eseguito con l'account dell'owner del job, indipendentemente da chi lancerà l'esecuzione del job.
2. Lo step è di tipo CmdExec oppure ActiveX Script
Se l'owner del job è un account che fa parte del...
posted @ lunedì 11 luglio 2005 20:53 |
Per ora l'articolo è solo in inglese, ma la risposta è qui:
http://www.davidemauri.it/dasBlog/PermaLink.aspx?guid=7d29ebf0-7fce-4ecd-937f-69be3e34d43d
L'articolo tratta in particolare dell'esecuzione asincrona, ma può essere anche tranquillamente utilizzato per l'esecuzione sincrona (che è di gran lunga più facile, in quanto basta eseguire la stored procedure sp_start_job.)
posted @ lunedì 11 luglio 2005 20:50 |
Bella domanda.
Visto che la CTP di Sql Server 2005 è finalmente feature complete, e che quindi è possibile cominciare a fare dello sviluppo "serio", è ora di cominciare anche ad aprire il vaso di Pandora delle nuove e contestate feature di Sql Server 2005. Una delle più interessanti è senza dubbio il nuovo tipo di dato xml.
Lasciando stare le risposte derivanti da fondamentalismi (passatemi il termine un pò forte ) circa convizioni più o meno religiose sullo uso di XML all'interno di un db, veniamo all'atto pratico: xml serve davvero? se si, in quali casi?
La prima risposta che...
posted @ martedì 19 aprile 2005 17:29 |
Per chiudere il cerchio sull'argomento "Date e SQL Server" è bene, anzi è obbligatorio, parlare anche degli orari. Non è un caso che il tipo di dato si chiami datetime. Come detto in precedenza, SQL Server non è in grado di memorizzare una data senza appiccicarci anche l'orario.
Questo significa che se si specifica una data senza un orario, SQL Server mette quello di default, ossia 00:00:00.000; per questo motivo il confronto fra date può sembrare difficoltoso. Una query molto semplice come
SELECT * FROM Ordini WHERE DataOrdine = '20050117'
può diventare foriera di dubbi e problemi. Gli unici ordini restituiti...
posted @ lunedì 17 gennaio 2005 20:01 |
Uno dei problemi che più affligge chi si avvicina a SQL Server è l'utilizzo delle date.
Il campo datetime di SQL (oppure il più piccolo smalldatetime) sembra che a volte si comporti in modo misterioso e non sempre sembra essere chiaro come interpreta i valori che gli immettiamo: il formato è giorno-mese-anno, oppure mese-giorno-anno, oppure altro ancora?
Per evitare qualsiasi problema di questo tipo è sufficiente inserire e pensare alle date utilizzando il formato ISO annomesegiorno, senza separatori. Oggi, quindi, si scriverebbe come:
20050117
In questo modo, indipendentemente dalle impostazioni di localizzazione, Sql Server interpreterà correttamente anno, mese e giorno.
Spero che questo riesca a chiarire...
posted @ lunedì 17 gennaio 2005 16:05 |