DBGrid - questa mia sconosciuta

[petrusic]

Nel mio progetto di contabilità familiare, faccio uso di griglie di dati che vorrei fare funzionare ora come dei veri e propri array, dove riportare tutte le colonne (visibili e non) delle tabelle logiche caricate in memoria tramite un'unica o più ZQuery (ancora non so come muovermi).
Fino ad ora ho utilizzato oggetti TStringGrid. Ora sto pensando di prendere conoscenza e sfruttare  le DBGrid con Zeoslib.
Nella brevissima guida ho letto che, nell'unica tabella fisica di esempio, si è dovuto aggiungere 

il campo IdPickExternalKey alla tabella principale in modo che faccia da chiave esterna ...

.
Se senza quel campo la DBGrid non funziona, allora posso gettare la spugna, perchè il DB in uso nel mio attuale progetto, scritto tuttto in Gambas, viene letto e aggiornato giornalmente e non posso stravolgere l'attuale funzionalità del software corrente.

Sto facendo poi una riflessione: Se avessi bisogno di scrivere una  "SELECT * FROM Tabella1, Tabella2, Tabella3  WHERE . . . " dove si costruirebbe una tabella logica con le colonne di più tabelle fisiche, come dovrei costruire la chiave esterna a cui si riferisce l'esempio della suddetta miniguida?

[DragoRosso]

Ok, se ho capito bene vuoi con una query interrogare tre tabelle e generare una unica tabella "virtuale".

A rigore di logica, una chiave "comune" è necessaria se devi collegare dei contenuti (righe) di diversi contenitori (tabelle).

E' particolarmente ovvio che qualcosa che lega i contenuti tra le tabelle ci deve essere, e quel qualcosa viene chiamato "foreign key". E' un concetto abbastanza comune, che può essere gestito anche senza questa "chiave" a livello di codice.

La chiave "foreign key" è il collante tra le tabelle e consente senza interventi di codice esterno di effettuare query più o meno semplici per aggregare dati.

Questa argomento è un pò più ampio e si collega alla progettazione dei database, avendo chiaro in mente cosa si deve fare. Nel tuo caso hai creato un insieme di dati per essere usato in una applicazione "GAMBAS", usarlo con un'altra applicazione potrebbe non essere così trasparente ed immediato.

Per poterti aiutare ci servirebberero ulteriori info sul database e sulle tabelle.

Ti posto quanto prima un esempio da cui puoi prendere spunto.

Ciao

[DragoRosso]

Esempio di join di tre tabelle senza foreign key.

Questa è la stringa SQL:

Codice: [Seleziona]

Select Utenti.Nome, Utenti.Cognome, ElencoScontrini.NumeroScontrino, Costo.Valore, ElencoScontrini.Data FROM Utenti join ElencoScontrini on RifUtente = ID join Costo on RifScontrino = ID1

In allegato database e printscreen risultato.

Ti lascio il piacere di "convertire" la stringa SQL per ZEOS 

[DragoRosso]

Questa invece è il database (sempre SQLITE) con una foreign key.

Sembra identico, e anche la stringa SQL è identica e ovviamente anche il risultato.

Allora perchè usare una foreign key ?

La risposta è semplice:

prova ad eseguire un inserimento nella tabella Costo di una riga con RifScontrino = 6. Fallo in tutti e due i database e vedrai la differenza.

A questo servono le "foreign key", a mantenere l'integrità dei dati .... almeno formalmente.
Spero di esserti stato di aiuto.

Saluti

[petrusic]

A questo servono le "foreign key", a mantenere l'integrità dei dati .... almeno formalmente.
Spero di esserti stato di aiuto.

Grazie per avere cercato di aiutarmi.
In verità avevo capito che la chiave esterna non è altro che una sorta di meccanismo automatico di sicurezza sui dati. Io volevo solo sapere se l'impiego della DBGrid per eseguire una query su Join di tabelle comportasse obbligatoriamente la dichiarazione di una chiave esterna.
Dai tuoi due esempi di DB SQLite, capisco implicitamente che l'obbligo assoluto non esiste.

Ora, considerando che io non voglio usare la DBGrid per inserire o modificare record, direttamente al suo interno, al fine di evitare  di modificare una casella al posto di un'altra (potrebbe capitare), dovrei impostare il parametro ReadOnly = False.

A questo punto, credo che tanto vale continuare ad utilizzare laStringGrid.

[DragoRosso]

.... al fine di evitare  di modificare una casella al posto di un'altra (potrebbe capitare), dovrei impostare il parametro ReadOnly = False.

Uhmmm ... direi ReadOnly := True.

Inoltre la DBGrid si "popola da sola" a differenza della StringGrid che devi popolarla a codice.

Ciao.

[petrusic]

Uhmmm ... direi ReadOnly := True.

Si, certo. Ho sbagliato  la selezione mentale. Anche questo può succedere 

Inoltre la DBGrid si "popola da sola" a differenza della StringGrid che devi popolarla a codice.

.
Be', ho già ottenuto qualcosina, ma nella testata delle colonne mi sono ritrovato coi nome di campo delle rispondenti colonne delle tabelle interessate nel DB. Quindi, per me è ancora tutto da scoprire.

Faccio un esempio:
Devo riempire alcune  colonne della DBGrid coi dati selezionati con la ZQuery  da 2 tabelle, però è anche possibile che, riga, dopo riga, possa dover aggiungere altri dati da selezionare in una terza o in una quarta tabella.
In questo caso, dovrò scoprire cosa succede. Poi devo anche scoprire come fare per scegliere sulla DBGrid la posizione delle colonne lette dalle tabelle del DB.
 

[DragoRosso]

Non sono un esperto dei componenti DB, però penso che tu non abbia molta scelta nella rappresentazione. Non penso che tu riesca a "maneggiare la griglia" una volta che il componente è agganciato ad una query.

O la query torna tutti i dati che ti necessitano o dovrai usare la StringGrid.

Poi c'è anche la possibilità di usare una tabella visrtuale creata da te che popoli come ritiene più opportuno e che può essere agganciata alla DBGrid. Però non ho mai usato questa tecnica e non saprei aiutarti.

Ciao