Newsgroup: it.comp.appl.access
Titolo: Inserimento dati tipo pivot-table

Avrei bisogno di un consiglio per un problemino credo abbastanza comune 
e quindi poi sfruttabile in molte altre occasioni
 
Vorrei realizzare una funzione che mi trovi il numero di giorni coltura 
di una pianta, in funzione di (almeno per me):
- tipo di pianta
- zona di coltura
- periodo dell'anno
- tipo di contenitore (cassettina polistirolo forata)
 
Ho pensato di realizzare una tabella CICLICOLTURALI con tante righe
Come campi essenziali:
-TIPO_PIANTA, ZONA_COLTURA, DAL, AL, C1, C2, ...C20
 
Dove da C1 a C20 sono le colonne che indicano il tipo di contenitore e 
che uso per memorizzarci i giorni di coltura di quella pianta, in quella 
zona, in quel periodo, usando il contenitore della colonna corrente
 
Ora, per andare va', perche ogni volta che la funzione GIORNI_COLTURA 
viene lanciata, filtra solo le righe della pianta scelta, della zona 
indicata, nel periodo piu' vicino a quello richiesto e poi va a vedere 
sulla colonna (C1 o C2 o C3 ...C20) il valore dei giorni di coltura da 
restituire
Il problema e' che cosi' ho un numero di contenitori fisso
E soprattutto se cambia l'anagrafica dei contenitori (tabella 
CONTENITORI) non c'e' piu' l'associazione corretta tra tabella 
CONTENITORI e COLONNA Cx nella tabella CICLICOLTURALI
In sostanza e' un sistema rigido che non consente la modifica agevole 
delle anagrafiche contenitori (non che si cambino spesso, ma capita che 
qualcuno venga dismesso, altri nuovi entrano in uso, ecc)
 
Come fareste voi per avere un inserimento dei CICLICOLTURALI su unica 
tabella con colonne C1, C2...C20 variabili nel loro numero?
In sostanza vorrei mantenere l'inserimento di UN record nei CICLI 
COLTURALI per definire i giorni coltura necessari per i vari contenitori
L'inserimento e la visualizzazione sono molto pratici in questo modo
Solo che la tabella dovrebbe essere 'a fisarmonica', ogni volta che 
inserisco in anagrafica un nuovo contenitore, dovrebbe apparire una 
nuova colonna nella tabella CICLI COLTURALI, ed oltra alla tabella pure 
sulla form che gestisce inserimento/modifica/cancellazione delle righe
 
Quindi, se  nella tabella CONTENTORI avessi 10 righe, nella tabella 
CICLICOLTURALI dovrebbe essere del tipo
TIPO_PIANTA, ZONA_COLTURA, DAL, AL, C1, C2, ...C10
 
Se  nella tabella CONTENTORI inserissi altri due nuovi record, e quindi 
avessi 12 righe, la tabella CICLICOLTURALI dovrebbe essere del tipo
TIPO_PIANTA, ZONA_COLTURA, DAL, AL, C1, C2, ...C12
 
Come fareste voi?
 
 
 
 
 
 


provo a dare un seguito, vedrai che non è proprio un consiglio ...
 
Poiché l'argomento è assimilabile a quelli che posso affrontare io
(di tipo tecnico-gestionale, non amministrativo),
riporto la descrizione di un MIO modo di procedere 
che NON si appoggia a "vere" anagrafiche.
 
Nel mio caso cerco di far comporre (agglomerare) dall'utente 
gli elementi costitutivi che fanno definire un "item di produzione"
per dare poi la possibilità di effettuare (o comunque registrare)
un "calcolo" tecnico, o un parametro fissato di esperienza.
 
Quindi per me gli elementi costitutivi sono:
 - tipo di pianta
 - zona di coltura
 - periodo dell'anno
che diventano attributi di una tabella
NOTA: NON è necessario neppure che ci siano TUTTE le tabelle con le liste
(le anagrafiche), io uso delle combo che si aggiornano con i nuovi inserimenti
(inghippo da ovviare: errore di scrittura, che permane  ...)
 
e l'elemento "TECNICO" definito di esperienza 
(o calcolato con eventuali altri dati presenti nella form) è:
- tipo di contenitore
- tempo di permanenza nel contenitore (se ho capito bene ...)
che sono attributi di una tabella SECONDARIA, DIPENDENTE da quella soprastante
(quindi "sopra" c'è un ID che "qui" diventa la key esterna)
 
Quindi l'inserimento diventa un tipico utilizzo di form e subform
con molte combo (utilizzo agevole, per il mio riscontro),
le tabelle "anagrafiche" sono poche
(come detto la lista univoca delle registrazioni proposta nella combo
sostituisce una anagrafica)
e poi le ricerche a video e i report sono piuttosto semplici
 


Si e' come dici
Ma per questione di praticita' di  visualizzazione ed 
inserimento/modifica dei dati, vorrei mantenere su UNICA RIGA sia quelli 
che tu chiami gli elementi costitutivi che gli elementi tecnici, senza 
usare form/subform
Attualmente la gestione e' su unica tabella,quindi alcuni campi sono gli 
elementi costitutivi, altri campi sono gli elementi tecnici, ma fissi 
come numero, e da questo deriva la rigidita' del sistema che vorrei 
migliorare
 
 
 

 migliorare
 
 
descrivo allora una cosa già vista da utente
(la consideravo disagevole, NON l'ho riproposta).
 
Una caratteristica dei tessuti è la loro composizione in fibre tessili,
per legge non si possono dichiarare più di 5 fibre,
la dichiarazione è fatta di due campi: siglaFibra, percentualeFibra.
 
Per registrare questa coppia ho SEMPRE trovato procedure con la "tabella piatta",
coppia di dati insieme agli altri propri di una anagrafica tecnica.
(mah, l'UNICA RIGA deve esercitare un' attrazione "fatale", è un vero colpo di fulmine ...)
 
La procedura faceva riempire le coppie di dati "a richiesta" (una coppia per volta),
e NON c'era il link "strutturale" ad una tabella master con i nomi DI CAMPO delle fibre come invece appare ci sia nel tuo caso, 
 
per me la causa principale della rigidità di adeguamento alle modifiche
è proprio questo legame strutturale (lo ritieni davvero utile ?)


La visualizzazione su un'unica griglia (una form continua) di tante 
righe, ognuna composta dai campi:
 
Pianta, Zona, Dal, Al, GiornixCont1, GiornixCont2, ..., GiornixContN
 
da' sicuramente una visione compatta ed efficace delle informazioni da 
mostrare
Il problema sta nel fatto che quei GiornixCont sono variabili
E se, dal punto di vista della memorizzazione potrei pensare anche ad 
aggiungere colonne (orrore) all'unica tabella utilizzata, dal punto di 
vista dell'inserimento/modifica/eliminazione la visualizzazione dati 
nella form non e' agevole
Non mi piace pee-gnente
 

 Non mi piace pee-gnente
 
solo per confermare di aver letto la continuazione:
 
poco da dire allora, 
penso tu sia "costretto" ad avvertire di dover intervenire
nel caso siano necessari nuovi contenitori,
 
infine, tanto per dire qualcosa e solo per coprire l'immediatezza, 
nella tabella contenitori si può aggiungere un descrittivo
e nella tabella di registrazione si possono tenere colonne in più
rispetto a quelle necessarie (di riserva), nascoste,
da scoprire quando si aggiunge un nuovo descrittivo nella tabella contenitori
(che, di fatto, rende "attivo" il record).
Il descrittivo diventa la LABEL della griglia di inserimento
e (se ho capito bene) si mantiene il vincolo C1, C2 ... già stabilito
che, così facendo, diventa essenziale (collegamento "di posizione")
 
 


Si, anche questa e' una possibilita',e onestamente non ci avevo pensato
Prevedere X righe massimo per la tabella CONTENITORI, corrispondenti a X 
campi nella form principale, oltre ai campi Pianta, Zona, Dal, Al
Solo le textbox corrispondenti ai contenitori presenti saranno 
visualizzati, e pure nelle label di titolo colonna posso metterci la 
descrizione del contentore (128F, 224F,...)
In questo caso l'unico limite e' il numero massimo dei contenitori possibili
Che essendo 'praticamente' sulla ventina/trentina, non dovrebbero creare 
problemi, dimensiono a 50 e chi s'e' visto s'e' visto
Certo che non e' una soluzione 'elegante'

 Certo che non e' una soluzione 'elegante'
 
faccio una sintesi
(come detto cerco di prendere spunti migliorativi
per gli argomenti che rientrano nella mia operatività,
e questo lo è)
 
Adopero diverse form di registrazione con aspetto grid,
ma NON sono a registrazione diretta
(NON adopero tabelle piatte e tra i passaggi di preparazione
c'è l'utilizzo della query a campi incrociati
che riunisce i dati da tabelle master-detail)
 
Per rendere agevole il riempimento delle "caselle" è bene
(tassativo ?) che le colonne abbiano un ordinamento adeguato allo scopo.
 
SE la grid è la "semplice" sequenza di campi di una tabella piatta 
(quindi a riempimento diretto)
E NON toccando l'aspetto della normalizzazione
(non sono io il suo paladino difensore)
 
viene "spontanea" questa considerazione:
necessita una certa abilità nel mantenere in gradevole sequenza
le colonne (i campi della tabella) che aumentano/diminuiscono nel tempo:
-abilità tecnica nel ridisporre quei campi con un nuovo ordinamento strutturale ogni volta che si apre la form di registrazione
-abilità nel trovarsi nella situazione fortunata in cui i nuovi nomi di campo sono "naturalmente" in ordine alfabetico
-abilità dialettica (formativa ?) nel presentare "quello che viene viene" quando nessuna delle due abilità precedenti è presente
 
SE la grid NON è a riempimento diretto 
(si registra da codice dopo gli inserimenti da tastiera nelle "celle")
si prospetta, grosso modo, una situazione sempre uguale
(dopo aver terminato la riunione di tabelle master-detail):
 
Ci sono dati "master" (in genere più celle, come viene anche a te)
che hanno un id di riga nascosto da gestire "in blocco",
ci sono dati "detail" (classici: qta E il nome della colonna ...)
da gestire singolarmente con la logica della battaglia navale
(id di riga come key esterna, nome campo in alto)
 
Inconvenienti dichiarabili (più miei che oggettivi ?):
-NON si può aggiungere una colonna direttamente nella grid
(occorre ripartire nella preparazione)
-DEFINIRE (e avvertire l'utente) quando si considera valida una registrazione
(considerando di NON avere tutte combo, con AfterUpdate a portata di click)