Newsgroup: it.comp.lang.visual-basic
Titolo: [?] Baco in Access?

Mi sembra un baco in DAO+Access (in ADO+SQL Server non ci sono problemi, non
ho provato in ADO+Access):
VB6 SP5, DAO 3.6, database Access in formato 97.
Creare un tabella TAB1 con i seguenti campi: ARTICOLO (dbText,22), UM
(dbText,2), IVA (dbInteger), VALORE_UNIT (dbDouble) e altri campi come si
desidera.
Creare un indice contenente tutti i campi citati (ARTICOLO, UM, IVA,
VALORE_UNIT), chiave primaria e univoca.
Creare (fra eventuali altri) un record con questi valori: ARTICOLO='1',
UM='MT', IVA=2000, VALORE_UNIT=4.81
(In effetti, è significativo solo il VALORE_UNIT e deve essere esattamente
con 4.81. Con altri valori che ho casualmente provato non ci sono problemi,
ma con quali altri valori "paragonabili" a 4.81 e che non ho provato il
problema si presenterà?)
Cercare il record con una SELECT * FROM TAB1 WHERE ARTICOLO='1' AND UM='MT'
AND IVA=2000 AND VALORE_UNIT=4.81
A me non lo trova.
Cambiando valore (per esempio 0.51646) lo trova.
Ho pensato che Access (o DAO?) scopra che i campi della sezione WHERE sono
identici (non importa la sequenza) a quelli dichiarati nell'indice e segua
una strada che lo porta ... al niente.
Ho inserito un altro campo (dbText,25) con contenuto univoco e l'ho messo in
chiave, ma, attenzione, non in coda ai campi prima definiti, in testa o
all'interno della loro sequenza. Il record viene trovato. Suppongo, per il
motivo opposto al precedente, che segua la strada "non ottimizzata
sull'indice", senza intoppi.
Avete qualche altra spiegazione? Grazie.

ho fatto il test e a me lo trova...
domanda stupida: non č che stai inserendo il dato con 4,81? (la virgola a me
la ignora access97, e il valore nella tabella risulta quindi essere 481,
invece 4.81 lo inserisce e trova correttamente)
Ho provato direttamente con query di access, questa la query risultante (che
trova il valore):
SELECT Tabella1.articolo, Tabella1.Um, Tabella1.iva, Tabella1.valore_unit
FROM Tabella1
WHERE (((Tabella1.articolo)="1") AND ((Tabella1.Um)="MT") AND
((Tabella1.iva)=2000) AND ((Tabella1.valore_unit)=4.81));
1 record restituito

 1 record restituito
Ma l'indice l'hai messo come ho detto?
Prova anche con Select *
Grazie.

 VB6 SP5, DAO 3.6, database Access in formato 97.
Stessa configurazione, SO Win98
ho costruito direttamente la tabella in access, non da codice, non so se
questo influenza il test
ho introdotto i dati da te indicati sempre direttamente in access (ho dovuto
scrivere 4,81 perchč 4.81 me lo prendeva 481)
ho fatto un programmino vb con questo codice
Private Sub Command1_Click()
    Dim d As Database
    Dim a As Recordset
    Set d = OpenDatabase(App.Path & "\db1.mdb")
    Set a = d.OpenRecordset("SELECT * FROM TAB1 WHERE ARTICOLO='1' AND
UM='MT' AND     IVA=2000 AND VALORE_UNIT=4.81")
    If a.RecordCount Then
        Text1 = "Lupo ha torto" ' ;-)
    Else
        Text1 = "Lupo ha ragione"
    End If
End Sub
Premendo il pulsante su text1 compare "Lupo ha torto", per quanto possa
avere valore......
Faccio un'altra prova immettendo i dati da codice....
Salutoni
Sergio

 Faccio un'altra prova immettendo i dati da codice....
Prova effettuata, il risultato non cambia.... il record viene trovato
sempre...
Facci sapere.... siamo curiosi (plurale maiestatis)
Salutoni
Sergio

 Prova anche con Select *
Provato, tutto ok...

Ecchevvidevodire? Sono affranto:
Non riesco più a riprodurlo (sic!). Nemmeno facendo le stesse cose di
stamattina.
Allora ho pensato che la mia macchina stamattina fosse imbogonata (non l'ho
mai riavviata, se non oggi al rientro).
Il fatto è che il mio collega, su altra macchina, presentava lo stesso
problema, testato appositamente.
Peggio ancora: La segnalazione mi perveniva da un cliente che sta a 800 Km.
Allora ho pensato: "è il mio programma".
No, perchè stamattina ho riprodotto il problema usando VisData, escludendo
quindi totalmente il mio programma applicativo.
Mi scuso per il tempo che avete perso.
Ho una sola certezza (se l'informatica non è un'opinione, ma lo è, oh, se lo
è!): Ci passerò sopra stanotte!

Perdona, ma ormai la curiosità è arrivata a livelli indecenti....
Il tuoi cliente ha ancora lo stesso problema?
Possiamo organizzare un pellegrinaggio? :-)
In qualsiasi caso tienici aggiornati!!
Salutoni
Sergio

 In qualsiasi caso tienici aggiornati!!
Non dubitare! ;-)

 problema si presenterà?)
8.37 e 9.37
???

 ???
Vuoi dire che il problema si presenta anche con questi valori?
Io, a differenza di quanto ho scritto nel precedente post, sono riuscito a
riprodurre il problema, ma non ho ancora trovato la serie di azioni esatte
da compiere per fornire elementi sperimentali necessari e sufficienti.


se ti č possibile prova se si verifica anche con questi valori
ciao

 ciao
Lo farò, ma tu non mi hai risposto.


qualche tempo fa ho provato a controllare il numero di decimali  inserendo
nella "proprietà" della tabella valido se
 =((Fix([IdValore]*100))/100)
dove [IdValore] è il campo della tabella stessa (numerico precisione doppia)
 il tutto funzionava tranne con 8,37   9,37  4,81
(ma cercando anche con altri)
ed ho  risolto con
=(Fix(CCur([IdValore1]*100)))/100
o anche con
=Fix("" & [IdValore]*100+Sgn([IdValore])*0,5)/100
ed il problema sembra simile
ciao

 ha scritto nel messaggio
news:alqmcs$i1i$1...@lacerta.tiscalinet.it...

ps
il tutto ha lo scopo di controllare se i decimali digitati sono superiori a
2
ciao