Newsgroup: it.comp.appl.access
Titolo: Progressivi in query con subquery, su chiave data...

Carissimi,
per calcolarmi un progressivo su Conto Corrente rispetto a movimenti
raggruppati per data, ho utilizzato quest'ultima per dire in una
subquery "sommami tutti gli importi dove la data e' inferiore a quella
del rigo e dove la banca di riferimento e' la banca X"... fin qui, tutto
ok, perche' la chiave "data" era fino a qusto momento univoca essendo i
movimenti raggruppati per la stessa (quindi una data, per una somma).
Il problema è sorto quando la data non e' più una chiave univoca.
E' sorto infatti l'esigenza di inserire, oltre alla gestione movimenti,
una primanota banca specifica su conto (per quadrature varia) che con
una UNION ordinata per data va a creare la composizione del conto
inclusi i movimenti inseriti in quest'ultima gestione.
Questo fa in modo che nella query, ci possano essere somme raggruppate
di movimenti al 1/1/13, ma anche singoli movimenti della prima nota
banca all' 1/1/13... in questo modo, il progressivo del conto, purtroppo
sballa, perche' prende i movimenti inferiori all' 1/1/13 per calcolarmi
il progressivo, e non va piu' bene...
 
idee?... avevo pensato a un numero da mettere su ogni record, ma da
query sarebbe cmq "on fly", e quindi non un numero da considerare
chiave... non vorrei trasportare tutto su tabella d'appoggio onestamete...
non mi raccapezzo.
 
Spero d'esser stato chiaro.
 
-- 
------------
Pablitomf
Napoli sempre nel "Q"uore!
"mammasantissima" si nasce, non si diventa.
 
TheSpaceCowboy : 
Britos deve recuperare per arrivare in forma al prossimo
infortunio - 24/10/12
 


No. anche alla luce di quello che ci siamo detti in altro post.
Normalmente, quando mi e' capitato di doverlo fare, ho sempre aggiunto 
un campo fittizio con un valore di tipo "tipo record" che mi consentiva 
di mettere i dati dove piu' mi faceva comodo e mi consentiva di poterli 
riconoscere e trattarli secondo la loro tipologia.
Cio' che consideri chiave o non chiave non e' /sempre/ in funzione della 
logica che applichi?
Un id, che generalmente viene trattato come chiave, talvolta non puo' 
diventare un semplice attributo?
 
-- 
 
ac (x=y-1)

 diventare un semplice attributo?
 
Alessa', ma se "ci fosse"... ovvio che e' un attributo, ma ti dicevo che
parte del contenuto era aggregato per data e somma importo... per cui
nisba ID...



Non mi sono spiegato.
L'id era solo un esempio.
Mi sembra di aver scritto che se non hai alcun elemento che ti consente 
di riconoscere quei dati /particolari/  abbiamo perso.
D'altra parte, come ultima spiaggia, citi che potresti utilizzare una 
tabella di appoggio.
La mia domanda.
Ma anche con la tabella di appoggio non avresti gli stessi problemi?
E se non li hai cosa renda la cosa possibile in un caso e impossibile 
nell'altro?
 
-- 
 
ac (x=y-1)

 ha scritto:

nella tabella di appoggio, accodo i dati... gli piazzo una chiave numerica PK
contatore, e quindi nella funzione di calcolo del progressivo non gli passo
più la data come paramentro ma l'ID (dicendo "somma tutti quelli con ID
inferiore a questo della riga")... ma mi scontro poi con il fatto che on-fly
non posso fare nulla se prima non passo i contenuti specifici sulla tabella...
ho più conti da gestire... diverrebbe un salasso... mhà...


 cui nisba ID...
 
Di quanti record per data parli?
1 somma = il record aggregato di cui parli soppra?
Cioč univoco in senso di: solo una somma per giorno?
+
1 record per le prime note per data?
 
Se sě, come suggerito da Alessandro basta di inserire un tipo
del record nell'UNION.
 
Se invece ci sono piů record per le prime note, non puoi passare
qualcosa univoca dalla tabella o le tabelle delle prime note?
Un Id o un ora d'inserimento che poi usi come secondo campo
per l'ordinamento.
 
Non disturba se le somme aggregate non hanno questo campo.
Nell'UNION per le somme puoi inserire NULL o ZZZZ per
regolare l'ordinamento.
 
-- 
Ciao
Karl
*********
Access FAQ:  
http://www.donkarl.com/it
 
 
 


Perche' non cerchiamo di ridurre il sistema all'essenza?
Mi sembra di aver capito che hai:
Una data
Un importo
Un conto
ed un tipo, che non c'e', che dice se quell'importo e' di tipo a o b
In che ordine ti arrivano? e cosa devi fare a seconda che il tipo (che 
non c'e') e' di tipo a o b
Cosa devi sommare e come?
Quali sono i raggruppamenti?
(insomma,qual'e' il tuo output?)
L'input e' piu' o meno chiaro.
 
-- 
 
ac (x=y-1)


mmmm
no... ho una
 
DATA - DESCRIZIONE - IMPORTO
punto...
 
questi sono popolati da "n" query che prendono dati da "n" situazioni... fin
qui, ok...
 
il problema è che io devo ottenere un:
DATA - DESCRIZIONE - IMPORTO - PROGRESSIVO_IMPORTO
 
il campo PROGRESSIVO_IMPORTO ora lo ottengo con una subquery che mi somma tutti
i campi importo della stessa "vista", con data precedente a quella della riga
aggiungendovi l'importo della riga stessa.
 
Tutto funziona finche' la data e' "UNIVOCA" (percio' la chiamavo "chiave" - e
fin ora lo era univoca - ). Con la nuova gestione della prima nota banca, non mi
soffermo sul perche', le date non sono piu' univoche... ma per un movimento
all'1/1/13 ce ne possono essere altri "n" in quella data... da li' il discorso
subquery decade...
 
mi sono spiegato meglio ora? ;)


 regolare l'ordinamento.
 
Purtroppo niente ID... il contenuto e' aggregazione di piu' record in "n"
tabelle... cmq ho risposto ad Alessandro piu' approfonditamente... leggi
là... ;)



Si.
Non ho ancora compreso il tuo output.
Mi immagino che nell'output puoi avere piu' righe con la stessa data e 
quindi se fai la somma dei movimenti a data precedente hai sulle righe 
di output un saldo progressivo totalmente sbagliato perche' risommeresti 
per ogni riga -pari data- il saldo precedente. E' Questo?
 
-- 
 
ac (x=y-1)

 per ogni riga -pari data- il saldo precedente. E' Questo?
 
quindi hai capito :)
 
e' la' l'inghippo... 



Forse è un'idea del menga.....ma mentre fai l'aggregazione di 'n' tabelle nella query, non puoi aggiungere, a seconda dei casi, 'sommare si/no', booleano, per poter poi procedere correttamente?

 e' la' l'inghippo...
Mahh.... forse una volta nella vita una cosa del genere mi e' capitata 
ma in questo caso la mia riga di riepilogo precedente stava a se stante 
con descrizione=saldo precedente data l'ultima precedente al riepilogo 
importo = asterischi ed il
saldo precedente e /poi/ aggiungevo tutte le righe che volevo facendo il 
saldo progressivo.
Che tra l'altro, non conosco la tua applicazione, ma mi sembra la cosa 
piu' chiara da fare in reporting soprattutto.
Tra l'altro /leggendo tra le righe/ mi e' parso di capire che sta cosa 
la fai n volte (cioe' la esecuzione della query con subquery)
Se e' cosi' stai in campana ;-)
Per una cosa del genere, al tempo, un mio collaboratore ha rischiato la 
sodomizzazione :-)
 
 
 
-- 
 
ac (x=y-1)

> Forse è un'idea del menga.....ma mentre fai l'aggregazione di 'n' tabelle
nella query, non puoi aggiungere, a seconda dei casi, 'sommare si/no', booleano,
per poter poi procedere correttamente?
 
Non risolvi cmq...  


 sodomizzazione :-)
 
..se serve, come fai diversamente?



Dovrei saperne di piu'. Hai nominato i conti, dove stanno? ed ancora non 
mi hai detto che diavolo di output e'. Ste query con subquery a cosa le 
applichi (che struttura?) sono associate a report? a form?.
Insomma quante tabelle hai in input e quante strutture generi in output.
 
Non ti sto a spiegare il problema che ho avuto ma ti posso assicurare 
che era abbastanza complesso e praticamente realtime e quei "tordi" dei 
miei collaboratori riuscivano a darmi una risposta ogni tre minuti (ed 
era sql server) mentre i dati affluivano con cadenza di un minuto. 
Adducendo come scusa che c'erano troppe immagini (era na roba che girava 
in intranet). "un par de palle" facevano query da sbatterli al muro! 
(praticamente tutte Dlookup) ;-)
 
-- 
 
ac (x=y-1)