Newsgroup: it.comp.appl.access
Titolo: Performance subreport

ciao a tutti.
in un report ACCESS ho deciso di aggiungere un subreport.
mi aspettavo evidentemente un calo delle performance ma non
credevo fosse una roba così penalizzante.....
il sottoreport ha come origine una stringa SQL che in esecuzione non è
nulla
di che.... va via liscia come l'olio.
le domanda sono:
a) ci sono criteri particolari per rendere + performante questo
report+subreport ?
b) mi piacerebbe provare a caricare i dati nel report scrivendo del
codice VB piuttosto che lasciar fare tutto ala maschera e all'SQL
integrato. è fattibile ? se sì, brevemente, come ?
Grazie

 ha scritto nel messaggio news:1153312004....@m73g2000cwd.googlegroups.com...
ciao a tutti.
in un report ACCESS ho deciso di aggiungere un subreport.
mi aspettavo evidentemente un calo delle performance ma non
credevo fosse una roba cosě penalizzante.....
il sottoreport ha come origine una stringa SQL che in esecuzione non č
nulla
di che.... va via liscia come l'olio.
le domanda sono:
a) ci sono criteri particolari per rendere + performante questo
report+subreport ?
b) mi piacerebbe provare a caricare i dati nel report scrivendo del
codice VB piuttosto che lasciar fare tutto ala maschera e all'SQL
integrato. č fattibile ? se sě, brevemente, come ?
Grazie
[risposta]
Cali di performance per un subreport? Sembra strano ma che fa questo subreport? Utilizzi controlli non associati e funzioni DSum, 
Dlookup, etc. etc.?
Ciao.
-- 
Sergio MAZZA

 Sergio MAZZA
... fai finta di avere testate e righe di ordine, un form che chiede un
numero d'ordine e poi il report
testate = report principale
righe = Subreport.
non ci sono totali e niente di particolare ...... è un leggi scrivi
.... semplice semplice
un report di 4 pagine impiega circa 40 secondi prima di essere
presentato......
l'unico escamotage che ho trovato è stato alleggerire la tabella di
partenza perchè
è vero che poi il report finale è di solo 4 pagine, ma la tabella di
partenza (che genera il
sub report) contiene circa 40.000 righe. in questo modo effettivamente
va molto meglio
però ........ non è un granchè di soluzione.
Non essendo un praticissimo di access io per accedere ai dati ho
trovato il metodo
di una stringa SQL su recordsource del report. magari c'è un metodo
migliore e +
performante.....
tu cosa ne dici ?
grazie 1.000

 ha scritto nel messaggio 
news:1153724271.6...@i42g2000cwa.googlegroups.com...
... fai finta di avere testate e righe di ordine, un form che chiede un
numero d'ordine e poi il report
testate = report principale
righe = Subreport.
non ci sono totali e niente di particolare ...... è un leggi scrivi
.... semplice semplice
un report di 4 pagine impiega circa 40 secondi prima di essere
presentato......
l'unico escamotage che ho trovato è stato alleggerire la tabella di
partenza perchè
è vero che poi il report finale è di solo 4 pagine, ma la tabella di
partenza (che genera il
sub report) contiene circa 40.000 righe. in questo modo effettivamente
va molto meglio
però ........ non è un granchè di soluzione.
Non essendo un praticissimo di access io per accedere ai dati ho
trovato il metodo
di una stringa SQL su recordsource del report. magari c'è un metodo
migliore e +
performante.....
tu cosa ne dici ?
grazie 1.000
[risposta]
Se l'origine dei dati è sempre la stessa ma cambia la condizione puoi aprire 
il report con il metodo OpenReport e passargli solo la condizioneWhere; io 
partirei da questo.
Il passaggio successivo è la creazione di una tabella temporanea associata 
al report che viene riempita con i dati necessari (già filtrati) da query di 
accodamento.
Altri metodi non ne conosco; è da tenere conto che influisce anche la 
struttura delle tabelle, indici...
Ciao.
-- 
Sergio MAZZA 

Sergio MAZZA ha scritto:

..... come sempre le cose + semplici sono quelle che funzionano
meglio......
il metodo OpenReport l'ho già usato senza grandi benefici, ma hai
ragione pienamente
con il discorso del file temporaneo. in effetti con un database +
leggero gira decisamente meglio. a me il file temporaneo non mi era
neanche pasato per la capa ......
thanks !