23/07/2023 - GioMadda ha scritto:
dovendo utilizzare la colonna 1 per il funzionamento della cbo in cascata, mi succede che nella tabella del Data Base viene salvato il numero ID e non il testo
Prima di parlare di altro, penso che sia doveroso partire da questo.
Se vuoi usare una casella combinata, soprattutto a cascata, devi salvare il numero ID e non il testo.
Tra le migliaia di ragioni per il quale si deve usare il numero ID le principali sono:
Primo perchè è il modo naturale per cui è nata la casella combinata per usarla in un database relazionale.
Secondo perchè se nei dati testuali per errore, una volta scrivi Pippo, un'altra volta Peppe, ed un'altra volta Peppa, praticamente avrai tutto il database sballato e non ti ridiranno più i movimenti, le spese e le varie relazioni.
Quindi, prima di pensare a creare il database, secondo me dovresti studiare attentamente come funziona un database relazionale, come funzionano i controlli di access, perchè una richiesta del genere fa capire che siamo lontani anni luce dalla corretta realizzazione e comprensione di un database.
Detto questo, per capire come hai impostato il database, più che le maschere devi mostrare come sono relazionate tra di loro le varie tabelle, che sono il vero motore. In base a come vuoi realizzare le tabelle e relazionarle tra di loro, solo dopo si potrà procedere a realizzare le varie maschere, che potrebbero (non nella forma, ma nella logica) funzionare in maniera del tutto differente rispetto ai vari metodi.
Mettere in pratica quello che vorresti realizzare implica avere le idee ben chiare su cosa si vuole ottenere. Aanche se all'apparenza semplice, può nascondere grandi insidie, soprattutto nella parte della gestione delle entrate e delle spese, e in particolar modo se decidi di implementare anche la gestione dei vari conti correnti, delle carte di credito e del portafoglio liquidi. Tutte cose che implicano una gestione degli spostamenti dei flussi e dei movimenti di denaro che non ti vanno a modificare il montante totale dei risparmi disponibili, ma che sono movimenti che vanno registrati, ma che non possono generare aumenti o diminuzioni del capitale e che quindi non si risolvono con un semplice numero in negativo o positivo, registrato in una tabella, o con un semplice calcolo su un report o con una query.
Tanto per dire, già nella maschera di inserimento, noto che hai inserito contemporaneamente sia le voci di entrata che le voci di uscita.
A livello di record, come le gestisci?
Una bottiglia non la puoi riempire di sabbia e contemporaneamente di acqua e soprattutto, quando andrai a bere, non potrai bere solo l'acqua e lasciare la sabbia all'interno della bottiglia.
Entrate ed uscite, devono essere gestite separatamente ed archiviate separatamente, ognuna in un record specifico, anche se nella stessa tabella.
Al di là della violazione delle regole di normalizzazione, è un errore a cui non si potrà mai porre rimedio se nello stesso record hai due valori di origine e destinazione diversa.
O meglio. A volte lo si fa, ma le tecniche per discriminare i valori giusti, implicano tecniche molto avanzate di programmazione che esulano anche dalla competenza di un programmatore di medio livello.
Da quello che ho letto finora, manca il cuore del database. Cioè la tabella MOVIMENTI. Tutto quello che hai finora nominato sono semplicemente il contorno, o meglio i valori atomici, che serviranno per andare a popolare appunto la tabella movimenti.
Una tabella, dove per data, verranno archiviati i dati di Entrate/uscita, le cifre, la destinazione di spesa, chi ha effettuato la spesa, su quale conto imputare l'entrata e l'uscita e una breve descrizione del movimento.
Praticamente ti manca la scrittura contabile che una volta veniva effettuata sui libri mastri.
Per cortesia sarebbe il caso che ci mostri la finestra delle relazioni per vedere che tipo di tabelle hai creato e come le hai relazionate, perchè altrimenti stiamo solo parlando a vanvera.