Casella combinata maschera

[Chris78]

Ciao a tutti ragazzi,
sono nuovo del forum (e anche di access, se è per questo!)

Mi presento a voi con la seguente domanda:

Sto creando per il mio lavoro un database per gestire i clienti e i relativi ordini.

Ora, i prodotti che io vendo si dividono in tre grandi categorie:

1) Agende
2) Calendari
3) Quaderni per appunti

Quando un cliente mi fa un ordine, può richiedere, ovviamente, una certa quantità di ognuna di queste categorie di articoli.

Ogni categoria, però, ha caratteristiche diverse:

Le agende si dividono in settimanali e giornaliere...
I calendari in mensili e trimestrali...
Ecc...

La domanda che vi pongo è:

In una maschera di inserimento ordini, come faccio a "LIMITARE" i campi che appaiono alle sole caratteristiche "utili" per ciascun prodotto?

Es:

un cliente mi ordina AGENDE SETTIMANALI.
Ho bisogno di una maschera in cui scegliere tra le sole proprietà delle agende escludendo dalla scelta le proprietà tipiche dei calendari (Mensile, Trimestrale).

Spero di essermi spiegato.
Come mi suggerite di procedere?

Grazie in anticipo per le risposte!

[dodo47]

Ciao e benvenuto nel forum

fai una ricerca nel forum di: caselle combinate. Troverai anche qualche esempio.

saluti

[@Alex]

La risposta sarebbe semplice... ma credo non lo sia...!

In una gestione relazionale, vengono definite le relazioni tra le tabelle..., tu non ci dici come hai strutturato i legami tra i tuoi articoli...!

Un'articolo di fatto può avere N proprietà, la dove le proprietà sono più di 1 si evince l'esigenza di avere una Tabella in relazione 1(articolo)-Molti(attributi)...!
Per attributi intendo le proprietà dell'articolo ovviamente... e quì si apre poi il mondo della gestione Molti-Molti... ma evitiamo.
Se tu avessi sviluppato con quest'ottica avresti ottenuto semplicemente quello che chiedevi con una Query di selezione con criterio...!

Ora se non hai strutturato in questo modo, che è invece la base del concetto, ci risulta complesso capire il tuo progetto.

[Chris78]

Ciao Alex,
innanzitutto grazie per le prime indicazioni, che ho cominciato a mettere in pratica.

Seguendo i suggerimenti precedenti sono arrivato a questo punto:

Creata una tabella "Prodotti" così strutturata:

ID_Prodotto: Contatore (Chiave Primaria)
Prodotto: Testo

In tutto ho 3 records, rispettivamente:

1 Agende
2 Calendari
3 Quaderni

Ora, le agende si dividono innanzitutto in 2 macro-categorie: "Giornaliere" e "settimanali".
Ognuna di queste, poi, avrà diverse caratteristiche...

Come mi consigli di procedere dunque?

Grazie ancora!

[@Alex]

La cosa giusta da spiegarti credo possa metterti in grosse difficoltà... ma tant'è che io non mi sento di dirti cose "poco corrette" solo per farti finire male il lavoro...!

Quando si affronta una struttura Gerarchica serve pensare in modo gerarchico...!
Le tabelle gerarchiche sono complesse da gestire ed a maggior ragione da concepire per chi non ha già appreso il meccanismo.

Ti passo un esempio semplice dal quale partire per capire la cosa, su questo poi ti costruirai la tua gestione Articoli, che altro non è che una Gestione di Magazzino...!

Questo è un'esempio molto scolastico di come si può strutturare una relazione Gerarchica:
Distinte basi e funzioni ricorsive

Questo è un'altro esempio che riguarda l'EMULAZIONE di un TREEVIEW fatto con una ListBox sempre basato sul demo di Lorenzo...:
MS ACCESS Code Sample - versione usabile/accessibile
Fai attenzione che questo mio demo, pur BANALISSIMO che sia gestisce proprio la gerarchia...!

Se poi vuoi esagerare sull'onda di questi 2 esempi ho costruito un Demo, il cui scopo è sciocco IL RICETTARIO... per mia moglie..., ma la base di questo è esattamente la gestione di magazzino con la generazione di Distinte Base...
MS ACCESS Code Sample - versione usabile/accessibile
Questo però guardalo solo in uno spazzo di PAZIA o dopo aver assunto sostanze stupefacenti.... è veramente complesso da concepire...!

[Chris78]

Buongiorno Alex,
ti ringrazio per l'onestà della tua risposta.

A livello teorico, per me che sono davvero alle prime armi con access, il tuo ragionamento non fa una piega, ma ti confesso che quando sono andato ad aprire i file di esempio che mi hai proposto, non ci ho capito granchè!
Per non parlare del ricettario di tua moglie!!!!

In particolare, mi pare di aver capito che andrebbe creata una struttura ad albero, con delle relazioni padre-figlio tra un livello e l'altro.

Ma, correggimi se sbaglio, è un'altra storia rispetto alle relazioni uno-a-molti?

Cmq, mi documenterò e vedrò di capirci qualcosa, nel frattempo inserirò manualmente le peculiarità dei miei articoli!

[@Alex]

Buongiorno Alex,
ti ringrazio per l'onestà della tua risposta.

A livello teorico, per me che sono davvero alle prime armi con access, il tuo ragionamento non fa una piega, ma ti confesso che quando sono andato ad aprire i file di esempio che mi hai proposto, non ci ho capito granchè!
Per non parlare del ricettario di tua moglie!!!!

Quello è il mio giochino... il bello è che poi lei stessa non lo usa perchè dice che deve inserire tutto a mano...... ma poi mi sono chiesto se voleva che inserissi io tutto a mano...!?!?!?
vabbè...

In particolare, mi pare di aver capito che andrebbe creata una struttura ad albero, con delle relazioni padre-figlio tra un livello e l'altro.

Ma, correggimi se sbaglio, è un'altra storia rispetto alle relazioni uno-a-molti?

Cmq, mi documenterò e vedrò di capirci qualcosa, nel frattempo inserirò manualmente le peculiarità dei miei articoli!

Diciamo che sono un concetto ampliato, che sfrutta il principio della ricorsione.
In sostanza se pensi ad una struttura gerarchica, ti verrebbe da pensare ad una struttura con tabelle in relazione 1-M...!
La cosa non fà una grinza, è corretta, ma prova a pensare di dovera avere il numero di Livelli Variabile...!
La logica della relazione 1-M richiederebbe l'aggiunta di Tabelle ad ogni implementazione di Livello...!
Questo per chi sviluppa è improponibile, solitamente non ci si mette più mano nè alla struttura nè all'applicativo...(UTOPIA ovviamente).
Di fatto però l'applicativo non potrebbe essere flessibile.

La struttura gerarchica con Padre-Figlio invece ha proprio questo vantaggio, che è in grado di creare una Relazione 1-M con se stesso... usando opportunamente le Chiavi.

Questa è la struttura gerarchica.

Si complica un pò la sua gestione, ma effettivamente non nasce per Access che invece è nato per gestire solo legami di parentela 1... quindi Form-SubForm...!
Per applicativi Unbound, come appunto tutti... devi costruire le Query SQL per estrarre i dati... li la cosa diventa più facilmente gestibile...!