Newsgroup: it.comp.lang.visual-basic
Titolo: Impostazione e Apertura recordset

Buongiorno al newsgroup ,
Vorrei un consiglio su come impostare un'applicazione che principalmente
ruota attorano ad una tabella "Ordini", ormai con piu' di 100.000 record di
testata.
Al Monento apro un recordset globale all' avvio dell'applicazione "select *
from ordini ".
Il form di lavoro ha un datagrid collegato al recordset e tanti textbox per
vari filtri ( cliente, data, fatturato, consegna,....) si inserisco i filtri
, si avvia la ricerca e imposto un filter= "...." sul recodset principale.
Il datagrid si popola di conseguenza e l'utente scorrendo il datagrid
individua l'ordine/gli ordini che gli interessano e usando vari tasti
funzione ( F2..F10 ) apre tante ulteriori form per gestire l' ordine in un
master/detail , inserire il N° pacco e dati spedizione, inserire luogo
consegna, ecc... tutti questi form lavorano sempre sull' unico recordset
globale.
Aumentando la mole di records l' applicativo è lento, lentissimo.
Vorrei un consiglio, sapere se un unico recordset deve essee soppiantato da
tanti aperti e chiuso in ogni form.
Grazie,
Giuliana

 from ordini ".
Partiamo dal presupposto che tutto dipende dal dbms che utilizzi.
Se usi un Sql-Server, Oracle, MySql, DB2, o altri dbms server, il collo 
di bottiglia non è l'esecuzione delle query, ma il transito dei 
risultati in rete. Devi quindi minimizzare tale mole, ad esempio 
abolendo l'utilizzo dell'asterisco.
Il resto dei dati li reperisci al bisogno una volta scelto l'ordine su 
cui lavorare.
Se invece usi dbms basati su file, come Access, FoxPro, Clipper, e 
altra archeologia, il collo di bottiglia diventa l'esecuzione della 
query in rete, per cui può anche avere un senso un "select *", 
assolutamente senza Join e Order By.
Devi quindi identificare la causa principale della lentezza.
E' legata al reperimento dei dati? Allora, basta aprire i recordset in 
modalità asincrona, e l'utente non se ne accorge neppure.
E' legata alla gestione locale dei dati in Ram? Beh, allora l'unica è 
sezionare e gestire i dati limitatamente alla necessità contingente...
Ciao
Alberto
-- 
Si è visto di meglio,
ma si è scopato di peggio,
qualche volta a pago
e non erano neanche sempre donne
[Paolo]


Mi spieghi come in modo asincrono?
Grazie ,
Ciao Giuliana

 Mi spieghi come in modo asincrono?
Cosa sia una operazione asincrona immagino tu lo sappia.
Come si apra un recordset in modo asincrono, è banale ma fai prima tu a 
leggertelo su MSDN che io a trascriverlo qui.



Rigrazie, giuliana

 , si avvia la ricerca e imposto un filter= "...." sul recodset principale.
Quali sono le differenze tra impostrare la proprietà filter e fare una 
nuova select con clausola WHERE riaprendo il recordset?
Marco / iw2nzm

Marco Trapanese ha detto questo mercoledì :

Beh, se le righe sono 100.000, supponendo che uno si metta a 
giochicchiare con filtri a bassa selettività (diciamo un filtro che ti 
restituisca il 50% dei record), dovresti ottenere ogni volta 50.000 
righe.
Poi l'utente toglie il filtro perchè si è sbagliato, e tu ne devi 
richiamare nuovamente 100.000.


 richiamare nuovamente 100.000.
Intendi dire che è più performante usare la proprietà Filter, ho inteso 
bene?
Marco / iw2nzm

Sembra che Marco Trapanese abbia detto :

Dipende dalla selettività del Filter e dalla numerosità della tabella.
Nella situazione dell'OP, e supponendo filtri a bassa selettività, è 
meglio una select con 10 Filter, piuttosto che 10 Select.


 filter="id=12546" senza aprire ulteriori recordset.
Io vedo l'errore qua nella "select * from"
Siccome nel post precedente dici che questa select serve per individuare gli
ordini da lavorare (mettere il pacco, la data, ecc...), allora bisognerebbe
costruire la select solo con le righe dove si può [inserire N° pacco e dati
spedizione, inserire luogo consegna, ecc..]. Questa darà pochi record
(sempre) e subito, poi da qui scegli quello su cui lavorare.
Inoltre, non conosco mysql, ma la prima select, con le opportune condizioni
di cui sopra, deve essere di sola lettura, e solo la seconda con i requisiti
anche di scrittura.
Io partirei da queste piccole cose, che definisco di buon senso, poi
eventualmente se non dovesse bastare, si può passare ad altre cose da alta
scuola.
--
Greg

 Io partirei da queste piccole cose, che definisco di buon senso
Se per 'select con requisiti di scrittura' intendi che il recordset è 
modificabile e che passi attraverso l'Update del recordset stesso per 
le modifiche, parlare di buon senso è una parola grossa.


 le modifiche, parlare di buon senso è una parola grossa.
Non conosco mysql, ma se non è Update, in qualche maniera bisognerà pure
scrivere la modifica.
E immagino che pure in mysql una lettura sia meno "pesante" di una
scrittura.
Comunque, essendo moto diverso da access, non aggiungo altro su questo, e
tolgo il bollino del buon senso alla seconda parte del mio post :)
--
Greg

 scrivere la modifica.
Con Update in SQL, ad esempio.
