Newsgroup: it.comp.lang.visual-basic
Titolo: Ordinamento date...

ho un "piccolo" problema sull'ordinamento delle date...
Uso ADO, faccio una select: "SELECT * FROM tabella WHERE data >
#05/06/2001#"
a seconda della data, in modo (mi sembra) del tutto casuale, se mese e
giorno sono minori o uguali a 12, e quindi interpretabili anche al contrario
(05/06 o 06/05), ogni tanto mi ritorna i valori come se stessi utilizzando
la data in formato americano, ogni tanto no...
qualcuno ha qualche idea?
Grazie, ciao.

 ha scritto nel messaggio
news:9q93rc$ajp$1...@nreada.inwind.it...


 ha scritto nel messaggio
news:9q93rc$ajp$1...@nreada.inwind.it...


 ha scritto nel messaggio
news:9q93rc$ajp$1...@nreada.inwind.it...

Ovviamente hai usato il formato americano, vero? :)
#mm/dd/yyyy#
Ciao

Si deve necessariamente usare il formato Americano per evitare questo problema?
(cioč nel Db devo impostare il campo come un campo Con formato americano?)
Ciao SIMO


 ha scritto nel messaggio
news:STay7.18620$pm2.3...@news2.tin.it...



wrote:

Io ho risolto questi problemi utilizzando un campo numerico che
memorizza la data nel formato yyyymmdd.
Quindi la ricerca nella SELECT avviene per numeri e non per date.
Cosě non si puň sbagliare, mai.
Poi nel programma ci sono due funzioncine che convertono la data
prelevata dal db in "dd/mm/yyyy" quando devono farla visualizzare
all'utente oppure da tale formato a yyyymmdd per memorizzarla nel db.
Ciao,
Moreno
-- 
#sirri#@#
morenosoft.com#
(togliete "#" dall'indirizzo)
Moreno Sirri VB Site - 
http://www.msvbsite.net
---------------------------------------------------------------------------
Le risposte alle tue domande le trovi sul Sito Comune di questo NewsGroup:
 
http://www.it-lang-vb.net
---------------------------------------------------------------------------

 risultato come fosse fatta in formato italiano...
Appunto :)
Il mio post era ironico...
Con i DB le date devono essere specificate in formato americano se unsi i
"#".
In alternativa puoi fare un confronto numerico del tipo:
"SELECT * FROM Tabella where Data = " & CLng(Date) ' non considera ore
minuti e sec.
"SELECT * FROM Tabella where Data = " & CDbl(Now)  ' considera anche ore
minuti e sec.
Ciao

 > risultato che torna č RANDOM... cioč ogni tanto la select mi torna il


 "Data" in database lo consideri una data in formato italiano?
mannaggia!
Anche tu confondi la rappresentazione stringa di una data con il valore
data?
Il valore Data (dichiarato cioè As Date, o DateTime o come cavolo vuoi) è in
realtà un double la cui parte intera rappresenta i giorni dal 1899 e la
parte decimale le ore, min, sec dalla mezzanotte (vedi "Date tipo di dato"
sull'help).
La stringa di rappresentazione di una data è invece solo una conversione
"uman-readable" di un valore che altrimenti non avrebbe molto senso (es.
adesso è il 37180,
4185648148
. Forse sull'Enterprise avrebbe senso).
E i DB per capire che data intendi vogliono che tu usi "#mm/dd/yyyy#" (nota
le virgolette: è una stringa!).
Ciao

 wrote in message
news:9q93rc$ajp$1...@nreada.inwind.it...


 writes:
B> ... io preferisco usare un cose del tipo clng(data1) > clng(data2) ...
Affidabile solo dopo il 31/12/1899  :)
La  cosa  migliore  per  avere  un ordinamento  rapido  delle  date  è
memorizzarle in stringhe AAAAMMGG.
--
Gian Uberto| main(){printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}
Lauri      |                        David Korn, 1987 ioccc best one liner 
(aka saint)|-------------------------------------------------------------------
em@ail: 
sa...@eng.it
 ( vedere X-nospam nello header - see X-nospam in header )

 le virgolette: è una stringa!).
anche wingate assegna un numero del genere nel dbf di log, per indicare il
momento di una certa connessione. devo ancora affrontarlo con calma e sangue
freddo.
j.ent

 
Come ti hanno detto una data racchiusa tra # viene SEMPRE interpretata
come data in formato americano, che puoi confrontare col la data nel db.
Il campo nel database č semplicemente una data (memorizzata come double)
il fatto di americana o italiana č solo una questione di visualizzazione
e di interpretazione di stringhe contenenti date.
-- 
Samuele Battarra
prova il mio newsreader:
http://digilander.iol.it/battarsa/programmi/news/

 il fatto di americana o italiana è solo una questione di visualizzazione


 memorizzarle in stringhe AAAAMMGG.
La domanda verteva su quella query, senza cambiare il database ...
Personalmente non uso MAI i campi data perche` li trovo troppo 'pesanti'.
Se mi serve una data (o un'orario) uso un long e mi sono sempre trovato
bene.
Il sistema che uso e` lo stesso che proponi tu: YYYYMMDD, ma in formato
numerico, quindi assai piu` veloce.
BAU!

 
Be, ma in tal caso è un bug!
In realtà DOVREBBE funzionare come avevo detto io.


 In realtà DOVREBBE funzionare come avevo detto io.
anche windows in realta' dovrebbe funzionare.
tout court :)
ciao, j.

 
P.S.
Con che DB hai fato le prove?


 Con che DB hai fato le prove?
ci ho pensato anch'io dopo, ma ero via.
accss97, quando ho un attimo se recupero il post te lo mando.

 ha scritto nel messaggio
news:9qutml$q0f78$1...@ID-51318.news.dfncis.de...

Attenzione.
Ho notato una cosa carina:
Se scrivi
"Select * from tabella where data = '" & Format$(date, "dd/mm/yyyy") & "'"
in realtà con le impostazioni internazionali italiane equivale a
"Select * from tabella where data = #" & Format$(date, "mm/dd/yyyy") & "#"
Ma la prima è chiaramente una forzatura instabile, diciamo un "vizio di
forma".
Ciao

 Sarei curioso... non gli ho ancora visto digerire date se non in formato
mm/dd/yy.
vista la tua autorita', ho avuto il dubbio di avere sognato...
-- allora: vb5sp3, access97, tabella di ca. 16k schede:
select * from ark where ark.date between #01/01/1999# and #05/01/1999# order
by ark.date
--> restituite 1212 schede, 4gen99 a 30apr99 --> ok, perche' la precedente
nella tabella e' 31dic98.
select * from ark where ark.date between #01/05/1999# and #01/07/1999# order
by ark.date
--> 27, 6gen99 a 7gen99 --> ok (non ce ne sono del 5gen).
altro formato:
select * from ark where ark.date between #01/01/1999# and #31/01/1999# order
by ark.date
--> restituite 318 righe, 4gen99 a 31gen99 --> oops... ( che non vuol dire
object-oriented programming system :)
lo so anch'io che non c'e' un 31. mese, e che quindi non c'era ambiguita',
fatto sta che e' passato al sistema italiano senza batter ciglio, mentre se
accettasse *solo* il 
f.to
 usa avrebbe dovuto dare un errore.
controprova:
select * from ark where ark.date between #30/01/1999# and #31/01/1999# order
by ark.date
--> 9, 30 a 31gen99 --> la query gli e' piaciuta moltissimo, ho dato invio e
il rs era gia' li' :)
non so bene chi va a interpretare la data italiana fra vb, jet e dao. io fra
l'altro ho vb5 usa e office97 italiano. cmq, volendo essere sicuri di quello
che restituisce, mi sa che:
-- o si utilizza qualcosa tipo format(mmddyyy)
-- o si lavora su month(), day(), year()
qui fra l'altro io so cosa c'e' nella tabella. ma ci possono essere casi in
cui non lo si sa esattamente, e allora si prospettano restituzioni *molto*
rischiose.
ciao, a.