Newsgroup: it.comp.appl.access
Titolo: Alternative a DLookUp e simili.

Qualcuno, in una risposta tempo fa, mi ha scritto che bisognerebbe evitare l'uso di DLookUp nel codice VBA, ma ora avrei bisogno di suggerimenti.
Ho due casi: nel primo devo trovare un record che soddisfi una certa condizione, nel secondo mi serve il massimo valore in un campo Data e avrei usato DMax.
L'unica alternativa che mi viene in mente è usare una cosa del genere:
Set RST=CurrentDb.OpenRecordset("SELECT... eccetera.
È la strada giusta o c'è di meglio?
Grazie a tutti
Riccardo Baldinotti

 ï¿œ la strada giusta ...?
 
Sï¿œ.
Nel web ci sono anche esempi come sostituire le funzioni D... con 
proprie funzioni (che di nuovo usano dei recordset), p.e. 
http://www.allenbrowne.com/ser-42.html
 
 
 
-- 
Ciao
Karl
*********
Access FAQ:  
http://www.donkarl.com/it
 
Access Lobby: 
http://www.AccessDevelopers.org
 

 
 
Grazie, io esitavo a usare i Recordset perché mi sembrava una soluzione
piùComplicata=piùPesanteInElaborazione
Se così non è, allora mi scateno, e studierò anche l'esempio.
 
Riccardo Baldinotti

 Qualcuno, in una risposta tempo fa, mi ha scritto che bisognerebbe evitare l'uso di DLookUp nel codice VBA, ma ora avrei bisogno di suggerimenti.
 
Niente e' "buono" o "cattivo" in assoluto.
Se la Dfunction che uso non sta in una iterazione il sottoscritto 
continua imperterrito a usarla. E' piu' comoda (non fa confusione fra 
ADO e DAO, sempre che qualcuno ancora usi ADO) e fa esattamente quello 
che si fa con definizione, apertura, lettura, chiusura di un recordset.
Ripeto se la Dfunction /non/ sta in un  ciclo usare il recordset la 
trovo solo una perdita di tempo.
 
 
-- 
ac (x=y-1)
Aborro il Killfile
(La violenza e' l'ultimo rifugio degli incapaci -Salvor Hardin-)
 
---
Questa e-mail è priva di virus e malware perché è attiva la protezione avast! Antivirus.
http://www.avast.com
 
 

 
Grazie anche per questa informazione.
 
Ehm... io ho usato il kill, recentemente... ;-)
 
Riccardo Baldinotti

 solo una perdita di tempo.
 
Programmando di solito si prescinde dal tempo
e dalla complessitï¿œ e lunghezza del codice,
obiettivo primario essendo l'efficienza,
vale a dire soliditï¿œ e velocitï¿œ dell'esecuzione.
Se ciï¿œ ï¿œ vero basare scelte di codice su comoditï¿œ
e semplicitï¿œ mi pare non abbia alcun senso.
 
Opinioni naturalmente, solo opinioni.
 
Bruno


Bruno intendevo entrambe le cose sia tempo di programmazione e aumento 
di complessita' del codice sia di tempo di esecuzione delle istruzioni.
Se ti scrivi una dfunction tua (che fa le stesse cose) e la richiami ci 
mette piu' tempo di quella fornita a sistema.
Anni fa avemmo un lungo "scazzo" con @Alex sull'argomento. (avemmo non 
e' plurale majestatis, se non ricordo male erano coinvolti anche altri 
"grandi vecchi")
Fatto sta, come ho gia' scritto, non mi sogno certo di usare quelle 
funzioni se devo inserirle in un ciclo e tanto peggio se devo metterle 
dentro una query. Ho altri modi per farlo proprio perche' il tempo di 
esecuzione (teorico) e' quello che valuto come prima cosa quando mi 
metto a scrivere codice (ormai raramente e solo se mi minacciano).
 
-- 
ac (x=y-1)
Aborro il Killfile
(La violenza e' l'ultimo rifugio degli incapaci -Salvor Hardin-)
 
---
Questa e-mail ï¿œ priva di virus e malware perchï¿œ ï¿œ attiva la protezione avast! Antivirus.
http://www.avast.com
 
 

 Access Lobby: 
http://www.AccessDevelopers.org
 
 
 
Che vantaggio c'e' a sostituire il dlookup con l'apertura recordset e 
filtraggio sulla select?
 
 

> Set RST=CurrentDb.OpenRecordset("SELECT... eccetera.
 
io ormai da tempo mi sto abituando a usare i RecordSet
potrai trovare nel link sotto qualche dettaglio in più,
 
soprattutto nella sintesi di "Silvio" del 27/11/2013
 
 
Certo che le funzioni D.... sono più compatte da scriversi,
 
ma alla fine un RecordSet fatto in quel modo occupa 1 sola riga e non deve essere richiuso o altro.
 
 
 
https://groups.google.com/forum/?hl=it#!topic/it.comp.appl.access/8pcHuFJ-75o
 
 
.


 
 
-- 
ac (x=y-1)
Aborro il Killfile
(La violenza e' l'ultimo rifugio degli incapaci -Salvor Hardin-)
 
---
Questa e-mail � priva di virus e malware perch� � attiva la protezione avast! Antivirus.
http://www.avast.com
 
 

 compattezza, ripeto,la sintesi .....
 
Certo ho detto che le D... sono più compatte,  ma ho indicato un link( non perché ne ero il propulsore ) che "rema" a favore dei RecordSet indipendentemente dalla compattezza ?? ......
 
 
Certo che bisogna contestualizzare,   ma a parer mio Silvio ha raccolto in
2 righe le migliorie proposte e discusse dai vari utenti
 
 
Adesso vado a dormire   cosi domattina mi alzero ( speriamo ) contento di bermi il mio solito caffe  :)
 
.
 
 


Le funzioni di aggregazione D<qualcosa>, usate singolarmente, non sembrano 
meno performanti di un'istruzione SQL avviata da OpenRecordset, quindi 
l'utilizzo delle due soluzioni è discrezionale.
 
Il problema delle DLookup, DSum etc. riguarda l'utilizzo nelle queries, 
quando vengono eseguite N volte (ma è lo stesso se le sostituisci con 
funzioni globali che sfruttano OpenRecordset(Stringa SQL) ).
In tali circostanze, danno apparentemente prestazioni migliori le 
SubQueries.
O forse no, guarda cosa scrive Karl:
 
http://www.donkarl.com/it?FAQ3.11
 
 
In definitiva è una matassa non semplicissima da sbrogliare.
 
Saluti. 
 
 

 filtraggio sulla select?
 
Sul link segnalato Allen elenca alcuni svantaggi delle funzioni D*.
 
Però la differenza più importante è che non possono usare degli indici. 
Se invece si filtra i dati con una istruzione SQL nel OpenRecordset gli 
indici vengono usati (certo solo se esistono nella tabella ;-).
 
Con dati locali e non molti record (tipiche tabelle "LookUp") non si 
vede grande differenze e anche io qualche volta uso un semplice D*. Però 
col backend in rete (possibilmente lenta e con molti record) la 
differenza nella prestazione puo essere enorme. In questi casi sempre 
uso un rs di DAO anche se tiro un solo record senza ciclo ecc.
 
-- 


 Adesso vado a dormire   cosi domattina mi alzero ( speriamo ) contento di bermi il mio solito caffe  :)
Come disse qualcuno andando a dormire un 29 Febbraio (valido soprattutto 
nella zona di Roma)
 
-- 
ac (x=y-1)
Aborro il Killfile
(La violenza e' l'ultimo rifugio degli incapaci -Salvor Hardin-)
 
---
Questa e-mail è priva di virus e malware perché è attiva la protezione avast! Antivirus.
http://www.avast.com
 
 

 ;-)
 
P.S. Non che tu sia un principiante ;-)


 Access Lobby: 
http://www.AccessDevelopers.org
 
 
Ah, quindi le funzioni D* non usano eventuali indici presenti nel db
Gia' questo potrebbe bastare a fare la differenza
Grazie 
 
 

 indici vengono usati (certo solo se esistono nella tabella ;-).
 
 
Ah, questo č interessante e decisivo!
Non mi pare che sia documentato sull'Help del prodotto, dove si trovano i 
dettagli?
 
Saluti 
 
 

 indici vengono usati (certo solo se esistono nella tabella ;-).
 
Sorry Karl ma dove viene precisata (dove posso trovare) questa storia 
degli indici? Sul link da te fornito non mi sembra ci sia alcun accenno
C'e, mi sembra, il solo generico riferimento alla primarykey che se 
assente potrebbe far si che il risultato sia "inconsistente" in casi 
particolari.



Ringrazio tutti per le considerazioni, che hanno arieggiato piacevolmente il mio cervellino.
 
Riccardo Baldinotti

Boh, da quando ho iniziiato ho usato sempre e solo Recordset, prima in DAO e 
ora in ADO.
Decisivo � stato un post di tanti anni fa in cui si faceva un confronto di 
prestazioni tra i 2 approcci.
Basta abituarsi a scrivere qualche riga di codice in pi�. 
 

 dettagli?
 
Purtroppo non so di nessuna documentazione tecnica delle funzioni D*.
Ci sono opinioni opposte su questa cosa e la mia puo anche essere ingiusta.
 
L'ha ottenuta da confronti di DLookUp e OpenRecordset che abbiamo fatti 
per una conferenza tanti anni fa (la documentazione solo esiste in 
tedesco). Perï¿œ ci sono sempre fattori multipli da considerare in queste 
prove. Per questo sarebbe "piï¿œ sicuro" di dire che in caso che se usino 
degli indici l'uso non sembra ottimo.
 
Tutte le prove con un semplice OpenRecordset con WHERE erano piï¿œ veloce 
di un DLookUp, con un oggetto db permanente molto piï¿œ veloce e con 
Seek(), cioï¿œ la cerca di DAO con un indice esplicito, era moltissimo piï¿œ 
veloce di DLookup.


 degli indici?
 > ...
 
Ah, come già risposto a Simone dovrei essere più prudente (credo che si 
dice "abbassare la cresta" ;-). Manca decisamente la documentazione 
tecnica per verificarlo.


 Basta abituarsi a scrivere qualche riga di codice in piů.
 
 
Penso che piů o meno tutti i frequentatori del ng. siano abituati a scrivere 
qualche riga di codice...
Tuttavia, ci sono circostanze in cui č comodo poterne usare una al posto di 
molteplici.
Ovvio che le problematiche prestazionali incidono sulle scelte (molto 
interessanti sono le considerazioni di Karl sul confronto Dlookup / 
Recordset).
 
Saluti. 
 
 

 potrebbe far si che il risultato sia "inconsistente" in casi particolari.
 
Questa notte, tanto per far qualcosa nel periodo insonne,
ho creato una tabella decuplicandone altra di poco piï¿œ
di 100 000 record, cosï¿œ ne ho ottenuta una da 1 milione,
nessun indice.
Una ricerca con DMax ha impigato 0.15 secondi, contro gli
oltre 0.50 secondi spesi con Recordset/SQL...
 
Bisognerebbe provare con le altre Domain Function, assegnando
indici, su diversi milioni di record... io non ne ho voglia.
 
Bruno