@ Gianluigi,
ti ringrazio per il complimento , ma, se non l'hai dimenticato, forse non sai che
fsurfing è un maestro, infatti mi ha insegnato a muovermi in SQLite.
A parte ciò non vorrei averti dato l'impressione di non avere apprezzato il tuo intervento. Ho solo approfitttao per mettere in chiaro alcuni aspetti, però SQLite non è un ambiente DB raffinato. Io inizialmente mi ero molto preoccupato sull'individuazione esatta delle primary key, considerando anche chiavi composte da più colonne, poi, quando ho capito che in effetti potevo gestirmi i criteri di relazionalità nelle istruzioni SELECT, ho deciso di assegnare il ruolo di chiave primaria ad un non necessario codice progressivo di numero di record, il cui compito è esclusivamente quello di sapere in ogni momento quante righe costituiscono ciascuna tabella del mio DB.
Quindi, scusami se ho dato l'impressione di apprezzare negativamente il tuo intervento. Tutti gli interventi sono costruttivi perché aiutano ad analizzare e considerare meglio nel dettaglio il problema posto dall'autore della discussione. Così come una discussione non serve solamente ad aiutare l'autore del post d'apertura, ma anche chi interviene successivamente.
Detto questo, vorrei cogliere l'ccasione per dare a
naderit un'altra dritta: non è necessario definire la colonna relazionale fra due tabelle del DB lo stesso nome, nel suo caso 'IDsocio', perché tale criterio comporta un'ulteriore specificazione referenziale della tabella di appartenenza di ciascuna delle colonne interessate in certe query.
Nel caso di utilizzo di query che impegnino, per es. sia la TAB1 che la TAB2, asrebbe necessario specificare a quale tabella si riferisce il codice 'IDsocio':
sql = "SELECT * FROM soci, quote ORDER BY soci.IDsocio, quote.IDsocio, anno"
. Diventa più semplice, per es. scrivere IDsocioT1, IDsocioT2, per distinguere quello interno alla Tab1 da quello interno alla Tab2.