Newsgroup: it.comp.appl.access
Titolo: Report con sottoreport con origine query basate su query a campi incrociati; errore "Impossibile utilizzare una query SQL di tipo pass-through..."

Salve a tutti,
ho la necessità di modificare il modo di visualizzare i subototali in un 
report con delle elaborazioni statistiche distinte per anni.
Faccio un esempio: supponendo di avere dei dati relativi ai comuni, ho 
bisogno di avere i dati per i comuni e poi i totali per provincia e regione, 
ma non intercalati tra di loro, così come è possibile fare in un unico 
report in access,  ma separati, cioè prima le statistiche relative ai 
comuni, poi insieme i totali per provincia e poi quelli per regione.
Per poter fare una cosa del genere ho creato dei sottoreport che ho inserito 
poi in un report principale.
Se collego il report principale all'origine dati con l'elenco degli anni, 
(in modo da avere per ogni anno i srReport di cui parlavo filtrati, senza 
dover modificare il filtro o l'origine dati di ogni singolo sottoreport) 
ottengo il seguente errore:
"Impossibile utilizzare una query SQL di tipo pass-through o una  query a 
campi incrociati a colonne non fisse come origine record di una 
sottomaschera o un sottoreport. Prima di associare la sottomaschera o il 
sottoreport ad una query a campi incrociati, impostare la proprietà
ColumnHeadings della query."
La query origine dei sottoreport è una query che mette insieme due query a 
campi incrociati, ognuna di queste con l'intestazioni colonne compilata. La 
prima ha le seguenti intestazioni colonne: "netto_gen, netto_feb, netto_mar" 
ecc, la seconda "lordo_gen, lordo_feb, lordo_mar", ecc. La query risultante 
ha così le colonne
"netto_gen, netto_feb, netto_mar, lordo_gen, lordo_feb, lordo_mar",  ecc.
Come posso risolvere? Se le query a campi incrociati coinvolte hanno tutti 
la proporietà "ColumnHeadings " correttamente impostata, quale è il 
problema?
Grazie a tutti
-- 
Nina 


Come fà un Report ad autodimensionarsi...?
Un'oggetto di quel tipo si genera avendo un RecordSource definibile,
il che comprende un Dataset strutturalmente immutabile, tant'è che
la generazione di un Report avviene in modalità Disegno o Struttura e
non Runtime..., a Runtime popoli solo i dati su una struttura
identificata.
Una Q_CampiIncrociati non ottempera a questi presupposti, quindi
quello che dovrai fare è gestire la cosa in modo non associato via
codice...
inserendo nel Report un numero di controlli ipoteticamente sufficiente
per soddisfare le esigenze senza dover ricorrere alla modalità
struttura.
@Alex

 Nina
Come fą un Report ad autodimensionarsi...?
Un'oggetto di quel tipo si genera avendo un RecordSource definibile,
il che comprende un Dataset strutturalmente immutabile, tant'č che
la generazione di un Report avviene in modalitą Disegno o Struttura e
non Runtime..., a Runtime popoli solo i dati su una struttura
identificata.
Una Q_CampiIncrociati non ottempera a questi presupposti, quindi
quello che dovrai fare č gestire la cosa in modo non associato via
codice...
R: Ciao Alex, scusa, ma l'impostazione della proprietą "Intestazione 
colonne" (ColumnHeadings riportata nel msg di errore) non serve proprio per 
definire "a priori" i campi risultanti da una query a campi incrociati?
inserendo nel Report un numero di controlli ipoteticamente sufficiente
per soddisfare le esigenze senza dover ricorrere alla modalitą
struttura.
R: Questo lo faccio quando non so a priori quali possano essere le colonne 
risultanti nella query a campi incrociati, per cui da codice associo ai 
controlli l'origine che mi ricavo da codice, ma in questo caso le colonne 
possono essere solo i mesi, io aggiungo soltanto l'indicazione "Netto" o 
"Lordo".
Forse non ho capito bene il tuo suggerimento
@Alex
R: Grazie
Ciao
Nina 

 Nina
Da quanto ne sò, o ricordo perchè di Report con Qry a campi incrociati
saranno 10 anni che non ne faccio..., il sistema
non è intelligente... e non sapendo discriminare a priori che il
numero di campi sarà al massimo 12 ricordo fosse proibitivo a
prescindere.
Il numero dei campi infatti dipende dalla presenza o meno dei dati
relativi "ai mesi nel tuo caso"... quindi ad esempio oggi non avendo
dati di Ottobre...Dicembre il numero
dei campi sarà 9... e questo perchè TU e solo TU sai che al massimo
saranno 12...!
Tuttavia, magari ricordo male... nel SitoComune era riportato un
Demo...
4.7 Report dinamici per rappresentazioni a campi incrociati
Non sò se ti è di aiuto...
@Alex




R: No, non è così proibitivo, credo che il numero delle colonne sia quello 
previsto per una query "normale", cioè 255 (questo almeno per quanto 
riguarda la versione di Access che uso io, cioè Access XP (2002). -
Il numero dei campi infatti dipende dalla presenza o meno dei dati
relativi "ai mesi nel tuo caso"... quindi ad esempio oggi non avendo
dati di Ottobre...Dicembre il numero
dei campi sarà 9... e questo perchè TU e solo TU sai che al massimo
saranno 12...!
R: Se indico la proprietà Column Headings il numero dei campi derivanti 
dall'operazione di "pivot" sarà quello del numero delle intestazioni 
indicate, a prescindere dal fatto che ci siano dati o meno (in mancanza di 
dati, il valore nella colonna corrispondente sarà null). Se vi fossero, 
teoricamente, altre colonne non previste nella proprietà ColumnHeadings, 
queste verranno ignorate e non mostrate nel risultato della query a campi 
incrociati. -
Tuttavia, magari ricordo male... nel SitoComune era riportato un
Demo...
4.7 Report dinamici per rappresentazioni a campi incrociati
Non sò se ti è di aiuto...
R: Questo report mi è stato d'aiuto tanti anni fa quando ho iniziato ad aver 
a che fare con report basati su query a campi incociati con intestazioni di 
colonna variabili, ma oggi il mio problema non è questo.
Se leggi di nuovo il mio messaggio iniziale, il mio problema è un'altro: mi 
appare il messaggio che consiglia di impostare la proprietà ColumnHeadings 
nelle query a campi incorociati, nonostante questa proprietà sia impostata. 
Non capisco quindi quale sia il problema. Se a qualcuno è già capitato un 
problema analogo, forse mi sa dire come risolvere o dove sbaglio. -
@Alex
R: Grazie mille per la disponibilità
Ciao
Nina 

 ha scritto nel messaggio 
news:4c873a0b$0$30912$5fc...@news.tiscali.it...

Ho trovato la risposta al mio problema (lo scrivo a favore di coloro che si 
dovessero imbattere nello stesso problema).
Il problema non è dato dalle query a campi incrociati, che hanno la 
proprieta ColumnHeadings correttamente impostata, ma dal fatto che si basino 
a loro volta  su una query di tipo pass-through (si tratta di un limite 
tecnico), non si possono usare query di questo tipo o query che si basino su 
di esse come origine record di sottoreport che si vogliono collegare ad un 
report principale.
Dovrò ovviare al problema in altro modo, ad esempio, inserendo da codice il 
filtro relativo all'anno, direttamente nella stringa sql della query di tipo 
pass-through.
Ciao
Nina 

 ha scritto nel messaggionews:4c873a0b$0$30912$5fc...@news.tiscali.it...

Ma tu non hai prospettato questo scenario... oppure mi sono perso
delle cose...? ;-)
In tutti i modi non avrei saputo darti suggerimenti risolutivi, quindi
benvenga il tuo spunto anche per altri utenti.
La soluzione che proponi come ben sai non implica perdita di
efficienza essendo eseguita SERVER_SIDE lo puoi verificare
dal Query_Analizzer.
Ciao
@Alex

@Alex
R:  Ciao, e grazie ancora per la disponibilitą
In pił di mille casi i tuoi suggerimenti sono stati importantissimi :)
Nina

 Nina
Inizio ad invecchiare... ed avendo abbandonato quasi completamente
l'aggiornamento tecnico fermo a 2003... non sviluppando ormai da anni,
mi accorgo di rimanere spesso indietro...!
Ciao
@Alex