Newsgroup: it.comp.lang.visual-basic
Titolo: Calcolo Nr. di unità di un articolo vendute

Ciao a tutti,
ho il problema di calcolare in numero di unità per articolo venduti in
un
certo periodo di tempo in Access 97.
Ho due tabelle "Acquisti" e "Articoli": la tabella Acquisti, oltre ai
dati
del cliente, ha 15 campi corrispondenti ai 15 articoli acquistabili;
in ogni
campo ci va il codice dell'articolo.
Ho pensato di fare in questo modo:
1. mi creo il recordset degli acquisti compresi in una certa data
2. ciclo su questo recordset e per ogni record "acquisti" ispeziono i
15
campi articolo, piazzando in un vettore il codice dell'articolo
eventualmnte
acquistato. Quindi se l'acquisto prevede 3 articoli (123 - 7 - 143)
aggiungere al vettorè i 3 elementi suddetti.
3. Il vettore creato conterrà il totale di tutti gli articoli
acquistati in
ordine sparso, ma no so ancora quante unità per ogni articolo: conto
allora
le occorrenze degli articoli, preoccupandomi di cancellare via via
l'articolo contato.
4. A questo punto, partendo dal vettore delle occorrenze saprò per
ogni
articolo quante unità ne sono state vendute.
Mi sembra tremendamente complesso: dipende dal fatto che sono le sette
di
sera passate o cè qualche altra soluzione?
Grazie in anticipo per l'aiuto.
Ciao,
   Giovanni
---
e-mail: gbuomm...@SoftHome.net
To reply please remove 'INGO'.
---
Ciao,
   Giovanni 
---
e-mail: gbuomm...@SoftHome.net
To reply please remove 'INGO'.
---

Scusami tanto...
Ma no ti conviene fare una SELECT con il raggruppamento  per articolo e
conteggio o somma per la ricorrenza???
Giovanni Buommino <gbuomm...@SoftHome.net> wrote in message
378e18d1...@frankfurt.news.okay.net...


...


rappresentata da un solo record.
Dovrebbe esere rappresentata da un solo record ?!!?!!!?!!?
Ora sono io ad essere perplesso........
La struttura dati che si applica x la soluzione di un determinato problema,
non e' uno standard ! Deve essere costruita su misura in base alle esigenze
del problema che si va' ad informatizzare dando e prevedendo situazioni e
casistiche particolari, mettendoci nella condizione che poi qualsiasi
interrogazione, statistica ecc. anche la piu' impensabile sia possibile da
effettuare senza dover poi stravolgere la nostra base dati o senza dover
dire a chi ci richiede una particolare funzione al nostro programma (sia
esso un utente o un cliente) un bel "Mi spiace...non si puo' fare " !!!!
Ciao
Ven.

sera passate o cč qualche altra soluzione?
Piu' che complesso lo definirei pazzesco! ;-)
Bai
<>====<>====<>====<>====<>====<>
Lorenzo Coronati
lore...@tin.it
reply: tin non e' una campana
ICQ# 6358211
<>====<>====<>====<>====<>====<>
<<L'intelligenza sta
dove l'ipotesi ammette
l'urgenza di lei>>

esso un utente o un cliente) un bel "Mi spiace...non si puo' fare " !!!!
Certamente la struttura dati adottata non deve essere sempre lo standard, ma
bisogna altresi` notare che avere un singolo record per ogni vendita
semplifica notevolmente il lavoro quando e` poi necessario fare statistiche
e reports. Diventa poi facile aggiungere o eliminare articoli senza dover
cambiare le struttura del database e quella del programa.Senza contare che
(eliminando casi particolari) contribuisce a limitare le dimensioni del
database.
Ma non sono  tutte rose: un approccio con un unico record contenente tutte
le vendite possibile, puo` aiutare ad accedere piu` velocemente ai dati e il
programma si semplifica un pochino. Ma il prezzo da pagare mi pare comunque
troppo alto: la flessibilita` e la riusabilita` del codice.
Tornando al problema posto da Giovanni, a me pare che convenga cambiare la
struttura del database per semplificargli la vita.
--
__AC__
============================
Sorry: E-Mail address not available!
============================

non e' uno standard ! Deve essere costruita su misura in base alle esigenze
Per questo avevo scritto "dovrebbe" e non "deve".
Ciao

Why ?
E' troppo limitato un approccio del genere, se poi ci vengono a chiedere il
cliente PIPPO quanti articoli  XYZ ha comperato a gennaio '99 dove ci
mettiamo le mano ??
Ma questo non e' che un esempio........
Ciao
Ven.


No, dipende dal fatto che hai una struttura del DB che definirei "strana"
(sicuramente non normalizzata).
Con uno schema database diverso avresti potuto fare tutto con una semplice
query con clausola GROUP BY (e moooolto piu' velocemente)...
--
Roal Zanazzi
z...@iol.it

 l'urgenza di lei>>
DOVE'E' CHE STA?!?!?!


L'intelligenza sta
nel considerare il progresso
come un aiutino da Domenica In
(Max Gazze' - Autoironia)