Newsgroup: it.comp.lang.visual-basic
Titolo: Grande quantità di dati in Recordset

Salve...
Il mio problema č: Eseguo una query su tabelle che contengono 30000- 40000
dati ciascuna..Il tempo di elaborazione č lunghissimo..e spesso non riesco a
vedere il risultato della query perchč il mio pc si blocca...Cosa posso fare
per velocizzare ??
Grazie
Pamela
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 Pamela
ciaociao

> Ti faccio una domanda: è STRETTAMENTE NECESSARIO caricare l'intero set di
record in un colpo solo?
 
Devo poi passarli a un report per la stampa..


 Devo poi passarli a un report per la stampa..
Quindi vuol dire che devi stampare 40000 record in un solo colpo?
mmmm....allora temo che tu debba innanzitutto crearti gli indici sulla/e
tabelle (se non l'hai già fatto), in più se utilizzi un db che le supporta,
potresti usare una StoredProcedure per reperire i dati.
ciaociao

> Quindi vuol dire che devi stampare 40000 record in un solo colpo?
Non devo stampare 40000 record ..ma devo interrogare 40000 record e più...Il
risultato che va in stampa potrebbe essere 1 record come anche 1000 o 10000
record..


 anche 1000 o 10000 record..
visto che stai parlando di numeri che, pur essendo grandi, dovrebbero
rientrare nella assoluta normalità, potresti dirci che query fai?
-- 
Salutoni
Sergio
per rispondere... togli il group dall'indirizzo

= " & dataDal & " )and Tessere.TesseraFidelity NOT IN( SELECT
VenditeFidelity_" & meseAl & ".TesseraFidelity FROM VenditeFidelity_" &
meseAl & " WHERE DataScontrino <= " & dataAl & ")"
 
            For i = meseDal + 1 To meseAl - 1
 
                query = query + "and Tessere.TesseraFidelity NOT IN (SELECT
VenditeFidelity_" & i & ".TesseraFidelity FROM VenditeFidelity_" & i & ") "
 
            Next
            If Right$(query, 5) = "UNION" Then
                query = Left$(query, Len(query) - 6)
            End If


 ha scritto nel messaggio
news:217Z58Z244Z158Y...@usenet.libero.it...

uhm uhm, leggendo le query, sembrano complesse, con SELECT annidate
soprattutto.
direi di aggiungere indici sul campo Clienti.CodSocio (dato che ci fai una
where).
Stessa cosa su datascontrino della tabella TesseraFidelity.
Che database usi? Se usi Access, prova, così giusto per vedere, se puoi,
msde o qualche altro db più performante.
good coding!!!
-- 
Alletun
"Io lo so che accadrà. La voce sussurra nei miei pensieri di Jair, Rone,
Allanon e soprattutto nelle Mortombre.
Sussurra segreti che mi sono tenuti nascosti, nella grigia oppressione
di questo giorno e nell'oscurità caliginosa di quello che mi aspetta.
Saremo distrutti. Tutti."
Brin Ohmsford - La Canzone di Shannara - T. Brooks

 query1 = "SELECT DISTINCT
 [...]
Intanto potresti usare le JOIN invece di annidare le select.
E insisto pure sulla SP, ma che db usi?
ciaociao

 good coding!!!
Ok provo a mettere gli indici su datascontrino..su codSocio c'è già..
e uso access..:(


 E insisto pure sulla SP, ma che db usi?
 
Access..


[Pamela = 
circa_...@inwind.it
 in
217Z58Z244Z158Y...@usenet.libero.it
] ha scritto:

Credo, inventando un mese da 3 a 4, di poterla tradurre in chiaro così:
SELECT DISTINCT
CodPdv,Clienti.CodSocio,Tessere.TesseraFidelity,Nome,Cognome,LuogoNascita,Da
taNascita,Indirizzo,Città,Provincia,Telefono,CapVersato
FROM Clienti,Tessere
WHERE
Clienti.CodSocio= Tessere.CodSocio
and Tessere.TesseraFidelity
NOT IN(SELECT VenditeFidelity_03.TesseraFidelity FROM VenditeFidelity_03
WHERE DataScontrino > = #03/01/2004# )
and Tessere.TesseraFidelity
NOT IN( SELECT VenditeFidelity_04.TesseraFidelity FROM VenditeFidelity_04
WHERE DataScontrino <= #04/01/2004#)
... il resto non è applicabile (For 4 to 3)
Se non ho male inteso, mi/ti domando: Nelle tabelle VenditeFidelity_03 e
VenditeFidelity_04 (che immagino strutturalmente identiche) non c'è il
codice del socio? Aggiungendolo nella Where si ridurrebbero di molto i
risultati delle subquery...
Per le stesse metterei anche un DISTINCT...

 Access..
allora niente SP... ;-)
prova allora, oltre ad aggiungere gli indici, a comporre la query usando le
JOIN fra le tabelle, cosě a occhio dovrebbe essere fattibile
ciaociao

secondo me se puoi sostituire le not in con delle outer join dovresti avere
un bel incremento di prestazioni... poi dipende dal numero di recond delle
tabelle che usi per le not in, ma le not in sono tendenzialmente
lentissimeeeeeeeee tanto che è consigliato almeno di usare la not exist



Carina la query... ;-)
A occhio direi che il DB è SQL Server, spero per te 2000... In ogni caso 
una ripassatina agli indici non fa male.
Bisogna sicuramente:
- Usare una SP. Molte delle condizioni che metti nel codice VB possono 
essere fatte da SQL direttamente, con grande vantaggio per l'overhead 
del client.
- Usare le join. Teoricamente l'optimizer di SQL Server dovrebbe fare da 
solo, ma tra il dire e il fare c'è di mezzo Bill... ;-)
- Ricontrollare la query. Non sono del tutto sicuro ma mi pare ci sia 
qualcosa di ridondante...
- Cambiare DBA. ;-) Trovo assurda una tabella che abbia come campi le 
vendite mensili di un qualche cosa... E' molto meglio, sia come ordine 
che come performance, una tabella con vendita e mese come campi 
separati, altrimenti come diavolo si possono impostare le relazioni??? 
Credo che questo sia il tuo problema principale che ti ha portato a non 
usare una SP con un po' di join carucce...
	Spero di essere stato utile (ma non credo!)
	S.
P.S: Ma sei la Rinaldelli?

 una ripassatina agli indici non fa male.
sbagli, dice che usa Access. Magari è SQL Server con le tabelle collegate ad
Access?!?!?!?!?!
oddio, spero di no.....:-))))
come fai a dire "a occhio direi che è SQL Server" ?


 e uso access..:(
DAO o ADO?
E su TesseraFidelity...

 come fai a dire "a occhio direi che č SQL Server" ?
Speranza? :-D
Parlando seriamente, mi pareva che richiedesse troppo overhead sul 
server dati per usare un db stand-alone come Access, di solito quando ci 
sono da fare cosucce cosě complicate si usa SQL Server... Ho escluso 
Oracle perché con PL-Sql la cosa si puň risolvere molto piů semplicemente...
  Di certo va un attimo rivista la struttura del DB, c'č qualcosa di 
strambo. Temo che anche aggiungendo indici le cose non migliorino poi di 
molto...
	S.

 Access?!?!?!?!?!
 NO...


 E su TesseraFidelity...
  ok!


 S.
son d'accordo. Solo che quando facevo consulenza in Cartasì, a Milano, ho
visto database di Access da quasi 1 Gigabyte contenenti i dati delle carte
di credito da produrre....
non ti dico che razza di query ci facevo girare: tempi di risposta da 4-5
minuti.....
:-((((


   ok!
Vedi anche l'altro mio post. Se c'è un codice socio sulle tabelle
VenditeFidelity_MM aggiungilo alla where interna. Metti anche la Distinct.

 VenditeFidelity_MM aggiungilo alla where interna. Metti anche la Distinct.
Nn c'è un codice socio nelle tabelle delle vendite....

 P.S: Ma sei la Rinaldelli?
        Cioč?????????????????!!!!!!!!!!!????????

 conviene provare con DAO?
Beh, a livello di sintassi devi modificare tutto il codice....
Come prestazioni perň il binomio Access+DAO dovrebbe essere piů performante
di Access+ADO
ciaociao

 provare con DAO?
DAO ti lega indissolubilmente ad Access, è il suo motore di accesso ai dati.
Lupo è contro ADO, troppo contro, non è attendibile (scherzo....)
effettivamente ha le sue grosse motivazioni per ritenere DAO migliore di ADO
in questo senso, però, ripeto il fatto di scrivere *bene* con ADO ti dà la
possibilità di cambiare db sottostante senza grossi sforzi.
come potresti fare adesso, leggi anche i post sotto perchè mi sa che danno
dritte very interesting!!!


 dritte very interesting!!!
Tipo usare i join anzichè i not in?

         Cioè?????????????????!!!!!!!!!!!????????
:-D Niente... Era una mia collega di qualche tempo fa che si chiamava 
come te e aveva spesso problemi di quel tipo... Per un attimo ho pensato 
di averla ribeccata.

 
Sorry, mi sono accorto di un mio errore nei post precedenti... Capo 
cosparso di cenere e procedo a spiegarmi:
Intendi i precedenti con: non 12 tabelle con le venditefidelity di ogni 
mese (ho capito bene?) ma una con in più un campo mese, vale tutto 
quello che ho detto prima, è sempre più conveniente...
Scusa di nuovo per il misunderstanding... :-(
	S.


Ok..ho capito quello che vuoi dire..Quindi conviene avere un'unica tabella
in cui ci sono 30000 * 12 record?

 Tipo usare i join anzichè i not in?
"not in" è male.
termoPilucco

 quello che ho detto prima, č sempre piů conveniente...


 Nn c'è un codice socio nelle tabelle delle vendite....
Fammi capire: un record che registra una vendita cita il numero della card e
non un codicillo che rimandi all'acquirente? Ovvero: ogni volta che
consideri una card non sai di chi è, se non dopo averla cercata tramite il
numero nella tabella Tessere e da questa rilevato il codice del socio?
Se è così, sono perplesso.

 
  Bé, con server database seri sicuramente, indicizzando ovviamente 
anche il campo mese... Credo anche con Access comunque.
	S.

= " & dataDal & " )and Tessere.TesseraFidelity NOT IN( SELECT
VenditeFidelity_" & meseAl & ".TesseraFidelity FROM VenditeFidelity_" &
meseAl & " WHERE DataScontrino <= " & dataAl & ")"
Te la potresti gestire con un solo passaggio ... e praticamente riduci a
metà
i tempi di lettura ...
poi perdonami, ma access per certe cose incomincia a diventare veramente
uno strumento da scartare. Vero che ci ho infiliato dentro 1 milione di
risultati,
ma vero pure che panino e bistecca tra una query e l'altra mi ci scappava
sempre.
Ciao
Andrea

 Premesso che non conosco il tuo retroscena...
Ti piacerebbe eh?! :-P

 Ti piacerebbe eh?! :-P
ROFTL, sul serio!!!!!!!!!!!
;-))))
-- 
Alletun


 Ti piacerebbe eh?! :-P
eh????!!!!????!!!!????!!!!!?????

[pamela = 
circa_...@inwind.it
 in
9kK5c.72334$
Kc3.2...@twister2.libero.it
] ha scritto:

Ah, Pam, non si puň scherzare? :-(
Com'č finita, poi?

 Com'è finita, poi?
E'  finita bene...Ho messo gli indici, ho messo il codice del socio nelle
VenditeFidelity, Ho utilizzato gli OUTER JOIN anzichè i NOT IN...e mi pare
basta...ora funziona molto molto molto molto....più velocemente...Non c'è
paragone...!!!
GRAZIE!!!

[pamela = 
circa_...@inwind.it
 in
JuK5c.72355$
Kc3.2...@twister2.libero.it
] ha scritto:

Bene.
Per gentilezza (e, fatto 30, per fare 31), ripubblicheresti quel blocco di
istruzioni modificato, per favore? Grazie.


Ah..dimenticavo..ho creato anceh una vista..
Domani mattina,quando sono a lavoro,pubblico il nuovo blocco..

[pamela = 
circa_...@inwind.it
 in
TEK5c.72375$
Kc3.2...@twister2.libero.it
] ha scritto:

Ecco, è proprio vero, non ho mai capito come trattare le donne... ;-(


Scusate voi..Ho avuto un problema grave e in questi giorni non sono andata a
lavoro...Non mi sono dimenticata di mettere la nuova query...appena rientro
la copio..
ancora grazie..

[pamela = 
circ...@inwind.it
 in mXl6c.75982$
Kc3.2...@twister2.libero.it
]
ha scritto:

Oddio, ora mi fai sentire in colpa... non volevo... :-(
Spero che non sia nulla di grave, in ogni caso, auguri.


TRanquillo..niente colpe...se è una cosa grave?..forse si..Perdere un'amica
per sempre..una ragazza di 22 anni che niente di male aveva fatto alla Vita
per perderla..
Scusate lo sfogo...nn c'entra niente quello che ho scritto...solo un pò di
rabbia...:(
grazie.

 pň di rabbia...:(
Ti capisco, ben piů di quanto possa far pensare quella che puň apparire una
"frase fatta".
Ho perso un'amica un paio d'anni fa, lei ne faceva non ancora 40.
Ha vissuto una vita d'inferno, per le persone che ha amato e perso e per la
malattia che l'ha colpita e se l'č portata via. Sono cose che, quando
accadono, mostrano tutto il loro peso e ne rendono difficile, fede o no, la
comprensione. Il sentimento piů naturale č, appunto, la rabbia e ... la
coscienza di quanto, in fondo, siamo piccoli. Poi, senza che questo
scandalizzi alcuno, passa, perchč cosě č giusto che sia. Aiutati.


Grazie.


accidenti :(((
mi dispiace tanto, spero solo non sia un incidente in moto, perchè a me di
amici me ne ha portati via 3....
fatti forza!
ciao

 fatti forza!
Una malattia...per quanto riguarda le moto...comincio a odiarle..me ne hanno
portato via uno..e mi basta...
Grazie..cercherò di farmi forza..