Newsgroup: it.comp.lang.visual-basic
Titolo: inspiegabile con access dateadd di minuti

RICETTA:
   prendete access 2000 o anche XP direi col 97 non so...
apritelo con un DB qualunque tanto non ci serve
create una query
andate in modalita' codice e incollate quello che segue:
SELECT Iif( DATEADD('n',30,#10.30.00#) = #11.00.00# , 'VERO' , 'FALSO') AS
VEROFALSO1
vi dovrebbe dare VERO
ora sostituite il codice precedente con questo:
SELECT Iif( DATEADD('n',30,#15.30.00#) = #16.00.00# , 'VERO' , 'FALSO') AS
VEROFALSO1
vi da FALSO
perche????
perche' 10.30 + 30 minuti fa 11.00
ma 15.30 + 30 minuti e' maggiore di 16.00 ?!?!?!?
VI PREGO AIUTATEMI!!!!
giova

 ma 15.30 + 30 minuti e' maggiore di 16.00 ?!?!?!?
Forse che DateAdd tra ore torni una stringa? Cosě va:
SELECT Iif( DATEADD('n',30,#15:30:00#) = "16.00.00" , 'VERO' , 'FALSO') AS
VEROFALSO1, DATEADD('n',30,#15:30:00#) as test
SELECT Iif( DATEADD('n',30,#10.30.00#) = "11.00.00" , 'VERO' , 'FALSO') AS
VEROFALSO1, DATEADD('n',30,#10:30:00#) as test
In entrambi i casi ritorna vero.
Ciao
*Roby*

 ha scritto nel messaggio
news:at631d$11ck03$1...@ID-94194.news.dfncis.de...

L'esempio che proponi e' corretto anche se in realta' dateadd ritorna un
valore di tipo datetime...
infatti un dateadd tra ore non e' realmente tra ore... se si omette il
giorno Access ci mette automaticamente il 31/12/1899 o giu' di li'...
usare una stringa come secondo termine dell'ugualianza non e' del tutto
affidabile...
oltretutto quello che ho proposto io era una semplificazione del problema
che consisterebbe in realta' nel fare una cosa cosi'...
DATEADD('n', CAMPO_MINUTI, CAMPO_ORAINIZIO) = #16.00.00#
cioe' in dateadd uso dei campi di un DB...
Cmq credevo che il prob fosse dovuto ad una strana conversione fatta per
passare dalla modalita' a 24 ore a quella a 12ore ma poi ho fatto questa
scoperta...
SELECT Iif( DATEADD('n',23,#14.00.00#) = #14.23.00# , 'VERO' , 'FALSO') AS
VEROFALSO1
restituisce VERO
SELECT Iif( DATEADD('n',24,#14.00.00#) = #14.24.00# , 'VERO' , 'FALSO') AS
VEROFALSO1
restituisce FALSO
e se faccio
SELECT Iif( DATEADD('n',2,#14.23.00#) = #14.25.00# , 'VERO' , 'FALSO') AS
VEROFALSO1
restituisce vero
BOH !
giova

[pgiova]
(snip)
Prima che albe V° si svegli, provate a fare mente locale alle impostazioni
internazionali, secondo le quali il separatore tra ore minuti e secondi in
italia è il ".", mentre in america è il ":"
Salutoni
Sergio

 ha scritto nel messaggio
news:at6sgp$10i099$1...@ID-173193.news.dfncis.de...

Sono sveglio, ma per qualche motivo i miei post, che sto scrivendo a tutto
spiano, non sono ancora pubblicati. Vi arriveranno tutti in un colpo, questo
compreso.
Sull'argomento, non credo sia un problema di separatori.
Io la vedo così:
I campi datetime sono in realtà memorizzati con una struttura simile al
double di VB. Questo significa che la rappresentazione sessagesimale è
solamente una delle possibili rappresentazioni. Il confronto fra due orari è
una cosa ad altissimo rischio di fallimento, perchè anche se visualizzati in
maniera identica, non è detto che siano anche memorizzati in maniera
identica.
Tempo fa feci delle applicazioni dove venivano eseguiti parecchi calcoli, in
alcune stored procedure di Sql-Server. Beh, a volte sembrava di essere
scemi. Roba tipo 1.0+1.0=1.999999999999999999, che dal punto di vista umano
è una cazzata, ma probabilmente considerando le rappresentazioni float e
real, ha una sua logica. L'importante è questa cosa rimanga come valore, e
mai come chiave. Ad esempio, se io volessi estrarre da una tabella un record
identificato da una chiave calcolata da operazioni sui float, sarebbe molto
probabile 'mancarlo', magari per qualche frazione infinitesima del valore.
Proprio per evitare queste cose, io ho scelto di considerare due orari
identici se differiscono per meno di un millesimo di secondo, usando il
datediff.
Ciao
Alberto

 real, ha una sua logica.
concordo, quando ci si trova a fare i conti con i double il problema della
"impossibilità" di riprodurre "esattamente" i numeri decimali è sempre
presente, e il formato date non è altro che un duble, la cui parte decimale
rappresenta l'ora.
Resta il dubbio, perchè non ho fatto, nè intendo fare, una prova in merito:
in sql è diverso scrivere
SELECT Iif( DATEADD('n',23,#14.00.00#) = #14.23.00# , 'VERO' , 'FALSO') AS
VEROFALSO1
oppure
SELECT Iif( DATEADD('n',23,#14:00:00#) = #14:23:00# , 'VERO' , 'FALSO') AS
VEROFALSO1
Punto di domanda
Salutoni
Sergio

 VEROFALSO1
Io la prova l'avevo fatta, e il risultato non cambia. Col tuo test dà sempre
"VERO".
E anche quello incriminato dà sempre falso (anche se non dovrebbe), sia coi
":" che col ".":
SELECT Iif( DATEADD('n',30,#15:30:00#) = #16:00:00# , 'VERO' , 'FALSO') AS
VEROFALSO1
Ciao
*Roby*

[Roberto Piazzolla] ha scritto:
(snip)
ok, direi che questa prova "risolve" la questione:
Private Sub Command2_Click()
Dim a As Double
Dim b As Double
a = DateAdd("n", 30, "15.30.00")
Debug.Print a
b = TimeValue("16.00.00")
Debug.Print b
Debug.Print b - a
End Sub
traduzione: i numeri sono diversi nei dintorni del sedicesimo decimale......
Salutoni
Sergio

 traduzione: i numeri sono diversi nei dintorni del sedicesimo
decimale......
Mi sa che ha ragione Lupo quando dice che le date sotto Access conviene
trattarle come semplici valori numerici...
a questo punto direi che la stessa considerazione vale anche per gli orari.
Sotto Unix, se mi ricordo bene,si usava un valore che rappresentava il
numero di secondi passati dal 1-1-1980. In quel modo, usando un double, di
problemi non dovrebbero essercene.
Ciao
*Roby*