Newsgroup: it.comp.appl.access
Titolo: findfirst DAO

Qualcuno mi fa un esempio come usare findfirst con Ado anzichč Dao ?
Saluti Max

 
non si puo'. ADO non possiede il metodo findFirst possiede il metodo 
find  (cfr help con magari movefirst)
--
ac

 ac

 Alessandro Cara wrote:
stamattina mi devo far vedere da un medico "bono" parlavi di ADO. Vale 
la prima che ho detto
--
ac

 find  (cfr help con magari movefirst)
Consiglio anche di dare un'occhiata al metodo Seek dei recordset.
--
PBsoft di Gabriele Bertolucci
www.pbsoft.it
skype: pbsoftsolution

 Consiglio anche di dare un'occhiata al metodo Seek dei recordset.
uhmmm... la seek se non ricordo male prevede gli indici.
Non ho nulla contro gli indici ma cerco di usarli solo quando servono.
Se le ricerche sono mirate solo su alcuni attributi indubbiamente con la 
seek dovrebbero migliorare le prestazioni, se si vuole un ampio grado di 
liberta' (ricerca su un attributo qualsiasi) non utilizzerei la seek.
--
ac

Vorrei sapere qual'è quella tabella in cui devi effettuare una ricerca
che
non possiede gli Indici.....?
Io mi auguro nessuna.
Certo Alessandro che in questo 3D te le sei dette, fatte e
risposte....!!!!!
;-)
@Alex


ohh Alex.
Alors. Ammettiamo che hai una tabella con trenta attributi.
Tu vuoi fare ricerche su tutti e trenta gli attributi con frequenze e se 
vuoi con pesi diversi.
Se usi la seek dovresti costruire trenta indici quando magari sottoponi 
la tabella a continui aggiornamenti.
Non conosco l'internal di access ma non credo che la gestione degli 
indici sia molto diversa da altri DB. In una situazione del genere ogni 
volta che fai un aggiornamento devono essere aggiornati gli indici 
(almeno uno) cio' porta, da parte del sistema,  ad un lavoro da fare 
sempre e comunque ed ad un progressiovo degrado degli indici con consumo 
di spazio e tempo e' necessita' di "riorganizzazioni" piu' frequenti, e 
secondo me pure "casini" nel caso di blocchi del sistema.
Per venire poi alla tua iniziale domanda. E' ovviamente una 
estremizzazione, ma si potrebbe comunque estendere. Se avessi una 
tabellina..ina..ina, e talvolta lo faccio, non definisco neanche la 
chiave primaria e le ricerche le faccio lo stesso. Il sistema comunque 
mi legge un blocco minimo (non so le sue dimensioni) che comprende 
certamente piu' di un record e per quel tipo di tabella se uso indici o 
non li uso non fa alcuna differenza. Ripeto qeste considerazioni 
derivano dalla conoscenza di altri DB e come ben sai, quando ad esempio, 
si fanno "massinsert" conviene fare la drop degli indici e ricrearli 
alla fine del processo. Generalmente tutte queste accortezze non sono 
necessarie in Access che, pur essendo in grado di gestire notevoli masse 
di dati, mediamente viene utilizzato per applicazioni di tipo "home", e 
per "home" intendo anche piu' stazioni e fino a 100.000 records.
Se si va piu' su diventano invece importanti le considerazioni 
"architettoniche" che hanno notevoli costi in termini di tempo speso 
solo ed esclusivamente per il loro disegno.
In finale poi Marzullo mi sta simpatico ;<)
--
ac

 ac
Ciao
@Alex
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 E' un tuo amico..?
No. Lo citavo a  causa della tua chiosa.
--
ac

 ac


 Reparto...!
E' un problema di lingua. per me sono tre attributi con 1000 righe (o
tuple come dicono i colti)
--
ac


prima del metodo Find usa MoveFirst
    rc.movefirst
    rc.find "..."
ciao,
Mat

Non è detto che serva, io vedrei bene di suggerire l'uso dell'Help
relativamente
al SearchDirection e Start prima di ricorrere al MoveFirst
Sub Find(Criteria As String, [SkipRecords As ADO_LONGPTR],
[SearchDirection As SearchDirectionEnum = adSearchForward], [Start])
    Membro di ADODB.Recordset
Saluti
@Alex