Originariamente inviato da garzone
codice:
Dim Data1 As String, Data2 As String
Data1 = Format(FrmConsumabili.TxtDataIn, "mm/dd/yyyy")
Data2 = Format(FrmConsumabili.TxtDataOut, "mm/dd/yyyy")
Set db_menu = OpenDatabase(Frmdb.TxtDbDati.Text)
Set rs_menu = db_menu.OpenRecordset("SELECT * FROM locale WHERE data BETWEEN '" & Data2 & "' and '" & Data1 & "' ", dbOpenDynaset)
scusa gibra ma sarò rinco io però non mi funge uguale
se metto # non va e neanche se metto le date in formato americano
Ma tu NON stai usando i cancelletti, ma gli apici!!!
Devi mettere entrambi!
Prova così:
codice:
Data1 = "#" & Format(FrmConsumabili.TxtDataIn, "mm/dd/yyyy") & "#"
Data2 = "#" & Format(FrmConsumabili.TxtDataOut, "mm/dd/yyyy") & "#"
SELECT * FROM locale WHERE data BETWEEN " & Data2 & " AND " & Data1
Ovviamente questo vale SOLO quando si usa il linguaggio SQL (come in questo caso).
Vi sono altri casi in cui le date vanno indicate normalmente:
1) quando si usano le query parametriche memorizzate nel database
2) quando si accede alle proprietà del Recordset


Originariamente inviato da garzone
il db è .mdb
campo data formato data dd/mm/yyyy
su access non posso impostare quello americano
Semplificando:
Access (come tutti i database) 'memorizza internamente' le date sempre nel formato americano (questa impostazione NON è modificabile in alcun modo), ma quando apri la tabella in ambiente MSAccess 'lui' te la mostra nel formato italiano (oppure quello delle impostazioni internazionale del tuo computer).
Ma questa è un'impostazione interna dell'ambiente MS Access che nulla ha a che vedere con l'ambiente VB6.0 e men che meno con ADO e DAO.
Ecco spiegato del perchè molti vanno in confusione.

Quando si usa il database da VB6, invece, ADO e DAO leggono e scrivono nel formato originale che è MM/DD/YYYY (quando si usa SQL, tienilo presente).



Originariamente inviato da garzone
lo so che dovrei in ado
Che usi ADO o DAO non fa differenza, sempre i cancelletti (#) ci vogliono.


Originariamente inviato da garzone
Anche eprchè mi è arrivato il libro per il 2010 e voglio dimenticare il vb6.
Ok, però sappi che anche in VB.NET la situazione non cambia. Non è una questione di linguaggio, ma di database.