L'unico formato asettico da qualunque impostazione è il formato ISO, ovvero "YYYYMMDD". Tutti gli altri sono sensibili alle impostazioni linguistiche in uso e che a diversi livelli (database server, login, regional settings, lingua del driver odbc/oledb, ecc) possono interferire con le tue intenzioni.
Segui questo esempio

SET LANGUAGE us_english
SELECT MONTH(CAST('2008-11-01' AS datetime))

SET LANGUAGE british
SELECT MONTH(CAST('2008-11-01' AS datetime))

e potrai verificare che il formato che stai utilizzando non è privo di ambiguità...

Bye

salve,
girub wrote:

grazie i l.bianchi ....nel primo caso il mese è 11 nel secondo 1. va bene così?
in realtà i campi sono datetime e aq me server vedere il range di ora perch+ comunuqe il giorno sono sicuro che è quello da un'altra condizione che imposto e che almeno questa funge...
ce forse qualche altro modo per confrontare le ore in sqlserv?
grazie mille della risposta... ste date e orari mi stanno facendo usci matto..

la verifica di confronto per la sola parte temporale, purtroppo, diventa "laboriosa" in quanto devi estrarre il datepart di ogni componente a te eventualmente interessante quindi, tipicamente, ora minuto e secondo, che puo' essere formalizzato in
DECLARE @d1 datetime, @d2 datetime;
SELECT @d1 = '19510831 12:30:45', @d2 = '20081125 12:30:45'; IF DATEPART( hh, @d1 ) = DATEPART( hh, @d2 )
AND DATEPART( mi, @d1 ) = DATEPART( mi, @d2 )
AND DATEPART( ss, @d1 ) = DATEPART( ss, @d2 )
PRINT 'la parte oraria è uguale';

personalmente pero', visto che vai ad applicare una funzione sulla parte temporale, eseguirei il confronto direttamente sull'intero dominio data+tempo, come anche tu hai gia' fatto, formalizzato in
DECLARE @d1 datetime, @d2 datetime;
DECLARE @r1 datetime, @r2 datetime;
SELECT @d1 = '19510831 12:30:45', @d2 = '20081125 12:30:45', @r1 = '19510831 12:30:40', @r2 = '20081125 12:30:30';

IF @d1 > @r1 AND @d1 <= @r2
PRINT '@r1 rientra nel range di data+tempo';

IF @d2 > @r1 AND @d2 <= @r2
PRINT '@r2 rientra nel range di data+tempo';

verifica quindi che, in effetti, i dati a tua disposizione rientrino correttamente negli intervalli temporali..
saluti

salve,
girub wrote:

grazie Andrea,
ti chiedo solo una cosa... ho provato questo tuo script nel front end di sqlserver è mi funge...

ma per poter utilizzare... questi comandi dovrei fare una
storeprocedure...?
come faccio a utilizzare... a fare un controllo.. visto che la mia query...è in una funzione dove gli passo le due date da
confrontare....

una funzione di che tipo? intendi una user defined function di SQL Server o una funzione del tuo applicativo?

Mi chiedo.. ancora.... non ci sono altre strade...
devo per forza ricorrerrere a una funzione o una store proc? Non potrei trasformare orario cosi come trasformo qui il giorno REPLACE(CONVERT(VARCHAR(10),[dbo].[Programma Scientifico].[Inizio], 111), '/', '')='20090205'

per poi confrontarlo come due interi?

non sono "interi", sono eventualmente rappresentazioni "testuali" di una data... un testo, qualora possa essere convertito in una data, viene automagicamente convertito in tal senso..
se tu scrivi
WHERE colonnaData >= '20081231 15:30:45'
il secondo viene convertito in una data (usa sempre questo tipo di formato per operare sulle date) ed il confronto avviene apputo tra il valore data della [colonnaData] e la conversione implicita del tuo parametro.. e proprio questo deve avvenire, a prescindere che la rappresentazione testuale possa sembrarti comunque "correttamente" interpretabile e valutabile { colonnaData = '20090101 0000' > '20081231 15:30:45' = true }
al di la' di questo, non e' ovviamente necessario ricorrere ad una stored procedure.. puoi tranquillamente ad esempio eseguire un command che includa questo codice SQL dinamico, similarmente a
dim cmd as SQLClient.SQLCommand
.....
cmd.CommandText = "SELECT ... FROM ... WHERE colonnaData >= '20081231 15:30:45' ORDER BY .. ;"
anche se personalmente sono molto riluttante all'utilizzo di codice di questo tipo, ma qui il discorso si fa "lungo e filosofico".. ti basti sapere che ovviamente, avendo codice SQL sparso per l'applicazione non potrai mai essere completamente sicuro dell'esposizione della tua superficie di attacco.. personalmente non concedo mai (ok, quasi mai) privilegi sulle base table e tutte le operazioni
(selezione/aggiornamento/inserimento/cancellazione) avvengono tramite apposite stored procedures.. gli utenti hanno solo privilegi di esecuzione di determinate procedure dipendentemente dalle loro qualifiche/necessita'.. a questo punto posso sapere per certo che una eventuale modifica puo' avvenire esclusivamente del codice SQL che e' sotto controllo completo [ovviamente eventualmente modificabile, nulla e' perfetto per definizione ] e so anche dove ricercarlo, senza fare ricerche paniche all'interno di codice sorgente applicativo che magari non conosco... dallo stesso punto di vista, so anche che l'eventuale errore non puo' essere chissa' dove e chissa' quante volte ripetuto, ma esclusivamente in 1 singola procedura, in quanto quella singola procedura e' l'unica che esegue la determinata operazione..
saluti