Grazie a tutti per le risposte.
Il database è ancora nella mia testa, quindi tutte le soluzioni sono attuabili.
L'esigenza era quella di gestire in modo elegante le differenze di denominazione delle taglie, sia per uomo/donna tipo (50-52) o (xs-s-m), quelle internazionali, quelli facenti parte agli accessori, alle scarpe ed alle cinture.
Ma questo problema è più semplice gestirlo cambiando semplicemente il testo delle label in fase di inserimento/visualizzazione, in base alle esigenze del momento e basato su una tabella di anagrafica delle taglie.
A dir la verità avevo pensato ad ognuna delle soluzioni proposte, ma sono tutte troppo complicate da realizzare, sia dal punto di vista del codice della struttura, sia dal punto di vista logico e di gestione.
Inoltre se qualcosa dovesse andare storto con qualche bug che mi va a creare dati incoerenti, sarebbe impossibile riuscire a metterci una toppa.
A dir la verità con access 98 avevo realizzato un piccolo gestionale, ma avevo creato una tabella dove ad ogni taglia corrispondeva un campo.
E ho l'impressione che la via più semplice e gestibile sia questa.
Alla fine ho solo circa 14 campi da gestire. Nulla che vada ad inficiare le prestazioni di access e avrei tra le mani un database con una struttura “banale”.
23/09/2023 - @Alex ha scritto:
Non puoi… ;-)
Diciamo che quella è una queey a campi incrociati quindi readonly.
Per fare una maschera di inserimento devi gestire tutto da codice in modalità NON ASSOCIATO e perdere la flessibilità di access…
Esatto, o meglio sarebbe una struttura tipo excel. A dir la verità avevo pensato di appoggiarmi ad excel, ma da access non potrei comunque modificare i dati del foglio, e se lo importo mi creerebbe comunque tutti i campi delle taglie. Tanto vale che lo faccio direttamente, creando una tabella con tutte le taglie, come avevo fatto nel database realizzato con access 98.
Nella mia mente bacata, mi era balenata l'idea di fare tutto manualmente e quindi ad ogni cella di una taglia, corrispondeva l'aggiunta di un nuovo record in una tabella dove avevo solo i campi ID, id articolo, colore, taglia e quantità.
Quindi archiviazione classica.
Ma già è un morir di pizzichi gestire il salvataggio, nel caso di modifiche alle taglie e quantità, sarebbe diventato veramente ostico riuscire a recuperare i dati.
Mi ero un po' gasato ripensando ai tuoi esempi di gestione spiaggia ed un altro che non ricordo, realizzati con le classi. Ma non è applicabile.
Senza considerare che avrei una caterva di record solo per gestire un centinaio di prodotti.
In passato ho usato un gestionale interfaccia Delphi, motore firebird che applicava una tecnica del genere.
Tutto bello, fino a quando non bisognava fare i lanci di produzione per articoli, colore, quantità, cliente e produttore.
Il sistema si bloccava per ore intere, inchiodando tutti i pc collegati, anche per estrapolare il lancio di un paio di articoli.
23/09/2023 - max.riservo ha scritto:
Un metodo un poco fantasioso : utilizza un campo Testo con cifre(caratteri) posizionali riferiti alle varie taglia (occorre rispettare una formattazione rigida).
Esempio (i trattini sono volendo superflui) :
“01-03-05-06-02-01” (Sono le q.tà riferite alle taglie 48-50-52-54-56-58 della polo)
Unisci i valori tramite concatenazione di stringe e li separi con lo split (in questo caso ti serve utilizzare un carattere separatore).
Per potersi fare, volendo si può fare, certo devi lavorare parecchio di codice e poi voglio vedere che fatica fai per estrarre le q.tà tramite le query (si può fare con una funzione VBA ma personalmente non lo farei).
Vedi tu …
Avevo pensato anche a questo, addirittura appoggiandomi ad un file TXT. Ma la cosa non mi toglie tutto lo sbattimento del codice e dai problemi descritti nella risposta ad Alex.
23/09/2023 - By65Franco ha scritto:
Ciao,
e un Array a due dimensioni ?
Pensato anche a questo. Mi sembra che è stata la seconda possibile soluzione.
Tra parentesi sarebbe quella più logica e semplice da usare. Caricare tutto in un array e poi creare i singoli record. Ma avrei aggiunto semplicemente un ciclo al codice che avrei dovuto scrivere per gestire manualmente la creazione dei record corrispondenti ad ogni singola cella.
23/09/2023 - sihsandrea ha scritto:
Una griglia di testo. Al click su conferma inserisci i valori delle celle ai rispettivi campi e record.
Per evitare l'uso di una matrice, avevo pensato anche a questo. Preso da un attimo di euforia tra parentesi avevo pure pensato di salvarlo in un file di testo. Ora a mente fredda non capisco a che cosa mi sarebbe servito il salvataggio.
23/09/2023 - max.riservo ha scritto:
Se come approccio già lo ritenevo poco pratico volendo anche gestire riga/colonna ritengo, sebbene fattibile, che sia un approccio da evitare, poi ognuno con i propri dati/DB ci fa quel che sa (o crede di sapere).
Concordo. Ma ero entrato in fissa che creare 14 campi con le rispettive taglie non era performante, elegante, inefficiente e soprattutto poco “professionale”.
23/09/2023 - By65Franco ha scritto:
creare una tabella temporanea per come vuoi rappresentare i dati e poi quando salvi riporti tutto nella tabella effettiva ?
Avevo pensato pure a questo. Addirittura creando i campi temporanei, dove ad ogni taglia corrispondeva un campo, per poi salvarli nella tabella principale in modo progressivo, con solo due campi. Taglia e quantità.
Poi ho capito che forse era oradi posare il fiasco, visto che avrei creato una tabella esattamente uguale a quella che andrò ad usare, far fare mille giri ai dati, per poi cancellarla.
Grazie a tutti. Penso che l'unica soluzione sia creare la tabella con tutti i campi corrispondenti alle taglie.
Per un attimo ci avevo sperato che potesse esistere una soluzione “Semplice” o magari qualche componente di access o activex che non conoscevo.
Ma si sa. Chi visse sperando…..