Newsgroup: it.comp.lang.visual-basic
Titolo: query con date

devo fare una query su di un database access, in cui i record vengono
selezionati per data.
Il risultato della query continua ad essere vuoto anche se la data in
oggetto esiste nella base di dati. Ho letto che c'è un problema di
compatibilità tra le date in formato inglese/americano rispetto alle date in
formato italiano (gg/mm/aa), ho dunque invertito nella query giorno e mese
ma continua a non andare.
VI mostro il codice:
    Set WS = DBEngine.CreateWorkspace(wrks1, "admin", "", dbUseJet)
    Set DB = WS.OpenDatabase(App.Path & "\acquarioDB.mdb")
    Set RS = DB.OpenRecordset("select * from agenda where data=10\21\02")
 (ovviamente ho provato anche con 21\10\02 ed è uguale.
Se non filtro i record con la condizione sulla data successivamente il
programma mi mostra
i dati perfettamente (e la data è della forma gg\mm\aa), quindi il db lo
apre bene e anche la tabella agenda esiste.Anche il campo data esiste e ci
sono vari record con data 21\10\02
cosa può essere?
grazie
ciao
--
The television screen is the retina of the mind's eye

 ma continua a non andare.
Usa sempre il formato #mm/gg/aaaa#, indipendentemente dalle impostazioni del
pannello di controllo (separatore compreso), quindi:
    Set RS = DB.OpenRecordset("select * from agenda where
data=#10/21/2002#")

 Usa sempre il formato #mm/gg/aaaa#, indipendentemente dalle impostazioni
del
Io mi sono imposto di usare il formato #aaaa/mm/gg# (č il formato Iso)
Non ho mai piů avuto un problema.

 Io mi sono imposto di usare il formato #aaaa/mm/gg# (è il formato Iso)
Ma funziona anche in Access???
Allora sono l'ultimo dei coglioni. Io uso l'Iso (be', in realtà diverso da
quello che indichi tu: io uso 'yyyymmdd hh:mm:ss') per tutti i DB, ma con
Access ho sempre pensato che non funzionasse....
Adesso provo.
Ciao
Alberto

 Ma funziona anche in Access???
Provato.
Dunque...
Effettivamente funziona con #yyyy/mm/dd#, ma non con 'yyyy/mm/dd' o
'yyyymmdd' (come con tutti gli altri DB).
Viceversa, in SQL non funziona con i #.
Per cui, in ogni modo occorre formattare le date in modi diversi per Access
e per gli altri DB.
A 'sto punto, continuo come fino ad ora (una funzione che mi formatta la
data come #mm/gg/aaaa# quando uso Access, e una come 'yyyymmdd' per gli
altri DB).
Ciao
Alberto

 Viceversa, in SQL non funziona con i #.
In Access+DAO o ADO uso #mm/dd/yyyy#
In SQL Server+ADO uso 'mm/dd/yyyy'
Non cambierò mai più. Il primo che mi costringerà a farlo verrà querelato.

 ha scritto nel messaggio
news:aWit9.64950$%M1.16...@twister2.libero.it...

Costringerti no.
Però un dubbio mi sorge spontaneo:
Per Access, so per certo che il formato che usi è universale, ossia
indipendente dalle impostazioni internazionali della macchina. L'ho provato,
lo uso anche io, e vado tranquillo.
Per Sql-Server, non sono affatto sicuro che il tuo formato sia indipendente
dalle impostazioni internazionali.
Addirittura, potrebbe dipendere dal login con cui ti colleghi.
Io uso 'yyyymmdd', e l'ho provato con Sql7, Sql2K, Inglese e Italiano, con
utenti con lingua default, Ita, Eng.
Temo che il tuo formato, in uno dei miei server con Sql-2K Eng, e con utente
con lingua Eng, potrebbe invertire le date dei primi giorni del mese (solita
storiaccia del 10 Marzo e del 3 Ottobre che si scambiano).
Magari, prima di decidere che quello sarà il tuo standard, prova a fare
qualche prova.
Ciao
Alberto



Lo cambierai da solo quando scoprirai che, almeno per sql server,
tale formato non e' sempre vero.
L'unico formato che vale sempre e' quello ODBC: 'yyyy-mm-dd'.
-- 
ciao, hal
se e' vero che prevenire e' meglio che curare, io ti ho avvisato ;-)

 L'unico formato che vale sempre e' quello ODBC: 'yyyy-mm-dd'.
Avete tutti il vizio di inserire dei separatori fra le cifre :-))
Oltre a non servire, rendono il formato non compatibile con tutti i sistemi.
Ad esempio, se vai su DB2, i trattini non vanno più bene, ecc...
Usa 'yyyymmdd', e ti semplifichi la vita, rendendoti compatibile con
praticamente tutto (tranne, come sempre, Access...).
Alberto

 praticamente tutto (tranne, come sempre, Access...).
Il punto, forse, č proprio questo (comunque verificherň con SQL Server):
Il separatore gli fa capire che le ultime sono quattro cifre (l'anno), non
so, francamente, come capisca che le prime due sono il mese e non il giorno.
Allo stesso modo, come fa Access? Mistero. Sono certo che (almeno in Access
con #mm/dd/yyyy#) il giochino del vedere se una coppia č maggiore di 12 cosě
facciamo un favore e la interpretiamo come giorno non viene applicato.

 L'unico formato che vale sempre e' quello ODBC: 'yyyy-mm-dd'.
Si, in effetti Iso mi risulta che preveda proprio il trattino "-" piuttosto
che "/" come separatore.
Comunque, tanto per approfondire un'attimo, la funzione dateserial di Vb
quanto può essere una soluzione da 1 a 10?
La sfiga è che bisogna sempre scomporre la data, ma basta una
funzioncina....
Ciao

 funzioncina....
    Domanda. Le espressioni:
        Str(CLng(data))
        Str(CDbl(dataora))
ovviamente senza delimitatori ne' di testo ne' di data , potrebbero andare
bene con un *ragionevole* numero di sintassi diverse? E quali? E quali
eventuali controindicazioni ci sarebbero?
--
Ciao :-)
Maurizio
--------
?SPQR(C)
 X
--------

Oltre a non servire, rendono il formato non compatibile con tutti i sistemi.
Da oggi, basta separatori :-)
Grazie, Albe, questa proprio mi mancava :-)
-- 
ciao, hal

 eventuali controindicazioni ci sarebbero?
Così di primo acchito controindicazioni particolari non mi vengono in mente.
Forse, si può facilmente incorrere in problemi di tipo non corrispondente...
mi vien da dire.
Comunque ottimo lo spunto...
Ci devo riflettere sopra

 Ci devo riflettere sopra
Una cosa
Se in sqlserver faccio un insert e per un campo di tipo date passo 29487 al
posto di 1980-09-23
Funziona?
Chiedo scusa ma now non ho la possibilità di fare una prova...
Con access non mi pare ci siano problemi.
Inoltre, su questo sono all'oscuro e mi piacerebbe capire meglio, la
sintassi Iso per datetime qual'è?
Qualcuno mi faccia sapere.