Report con sottoreport con origine query basate su query a campi incrociati; errore "Impossibile utilizzare una query SQL di tipo pass-through..."
Nina
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
@Alex
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
"@Alex" <ik2...@libero.it> ha scritto nel messaggio
news:eba264e3-482f-4a01...@l6g2000yqb.googlegroups.com...CUT
> 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
> 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
> "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
> 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...
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
@Alex
> "@Alex" <ik2...@libero.it> ha scritto nel messaggionews:eba264e3-482f-4a01...@l6g2000yqb.googlegroups.com...
> On 7 Set, 14:54, "Nina" <paninotCancellaredopopani...@yahoo.it> wrote:
>
>
>
>
>
>
>
>
>
> > Salve a tutti,
>
> CUT
> > 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
> > 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
> > "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
> > problema?
>
> > Grazie a tutti
> > --
> > Nina
>
> Un'oggetto di quel tipo si genera avendo un RecordSource definibile,
> 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
> 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
> 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
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
Nina
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
Nina
"Nina" <paninotCancell...@yahoo.it> 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
@Alex
> "Nina" <paninotCancellaredopopani...@yahoo.it> 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
Nina
> >> > 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
> >> > "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
> >> > problema?
>
> >> > Grazie a tutti
> >> > --
> >> > Nina
>
> >> Un'oggetto di quel tipo si genera avendo un RecordSource definibile,
> >> 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
> >> 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
> >> 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
>
> > saranno 10 anni che non ne faccio..., il sistema
> > numero di campi sarą al massimo 12 ricordo fosse proibitivo a
> > prescindere.
>
> > 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
> > 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
> > 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
>
>
> > 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
> > 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
> > qualcuno č gią capitato un problema analogo, forse mi sa dire come
> > risolvere o dove sbaglio. -
>
> > @Alex
>
>
> > Ciao
> > Nina
>
> Ho trovato la risposta al mio problema (lo scrivo a favore di coloro che
> si
> dovessero imbattere nello stesso problema).
> 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.
>
> filtro relativo all'anno, direttamente nella stringa sql della query di
> tipo
> pass-through.
>
> Ciao
>
> Nina
>Ma tu non hai prospettato questo scenario... oppure mi sono perso
>delle cose...? ;-)
R: Sģ, scusami, hai ragione. Purtroppo la mia attenzione nel leggere il
messaggio di errore si č soffermata sulla parte riguardante le query a campi
incrociati e solo dopo averlo riletto con maggiore attenzione mi č venuto in
mente che le query a campi incrociati avevano origine da una query di tipo
pass-through.
>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.
R: Sģ, va bene
>Ciao
>@Alex
R: Ciao, e grazie ancora per la disponibilitą
In pił di mille casi i tuoi suggerimenti sono stati importantissimi :)
Nina
@Alex
> R: Ciao, e grazie ancora per la disponibilità
> In più di mille casi i tuoi suggerimenti sono stati importantissimi :)
>
> 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