[DELPHI] ClientDataSet e tabelle collegate Master-Detail

[it9qbd]

Salve,
ho provato dietro consiglio di un utente di questo Forum, ad utilizzare i "tClientDataSet" per svolgere dei calcoli con le "aggregate" e "internalcalc" agganciate ad un "tDataSetProvider" collegato a sua volta a delle tabelle TABSTable di AbsoluteDB...
In effetti sia i calcoli che le ricerche "filtered" sono velocissime e molto semplici anche le operazioni di calcolo.
L'unico problema che mi rimane è dopo il post, precisamente applicando le modifiche alle tabelle che sono collegate tra loro essendo master detail, dandomi errore di chiave, ecc.,ecc.
Ho provato a cercare in rete ovunque, ma quello che ho trovato non è servito a farmi risolvere il problema, probabilmente mi sfugge qualcosa che non riesco a capire...

Spero che qualcuno possa veramente darmi una mano.
Grazie.

Dimenticavo uso Delphi XE.

[deleted_29]

personalmente ti sconsiglio di usare qualsiasi approccio che non sia "manuale".

ovvero crea delle procedure che fanno i calcoli, e chiamale al momento giusto (es. onexit dai campi ove inserisci i valori).

questo per portabilità, ossia facilità di migrare da abs ad altro (es. ZEOS e quindi mysql, firebird o quello che vuoi)
---
Anche per master-detail ti suggerisco brutalmente di usare due query diverse, una ovviamente per il master, mentre per avere il detail "aggiornato" metti un componente tdbedit con un campo chiave del master (es. un ser autoincrementante), e poi usa l'evento onchange per "refreshare" le righe della slave.

questo approccio funziona con (praticamente) qualsiasi engine, dalle tabelle memory alle mitiche paradox, mysql o quello che vuoi

PS è solo un suggerimento, intendiamoci... ma visto che hai un'applicazione più "intelligenza" ci metti dentro, meno ti leghi al substrato database, il che è cosa buona e giusta nel momento in cui lo vorrai sostituire.

[it9qbd]

Grazie del consiglio,
avevo già provato ad utilizzare delle query sia per master detail che per i calcoli, ma quando gestisco in una griglia molti dati, per per ottenere i totali (non tanto quelli della riga, ma quelli di tutti i record della dbgrid) noto che diventa molto lento e pesante...
Ecco perchè l'approccio al tClientDataSet, che fra l'altro mi da la possibilità di lavorare in cachedupdate e quindi annullare tutte le modifiche al db con un semplice comando...
Mi piacerebbe trovare un'alternativa semplice, ma non so che componenti db utilizzare per avere la portabilità di abs che non necessita di installazione e semplicità di gestione, con soli 2 files ho tutto ovunque.

Peccato perchè funziona tutto alla grande se non per applicare le modifiche finali al db.

[it9qbd]

Risolto finalmente il problema,
mi stava facendo impazzire....
Era semplicemente un errore sull'impostazione della chiave esterna.
Grazie comunque a tutti per la collaborazione.

[it9qbd]

In realtà non ho risolto un tubo, ho solo le idee più confuse....
Le relazioni master detail non funzionano bene in questo modo, anzi....
se prima funzionava tutto utilizzando le ABSTable adesso che ho aggiunto il tClientDataSet ho combinato un casino.
Mi sa che devo seguire i consigli del buon franzauker, dove posso trovare una buona guida ???
Qualcuno ha un progetto di esempio che possa aiutarmi a far lavorare due tabelle master detail con questo componente e che nonostante chiave primaria ed esterna impostati correttamente non mi dia l'errore 'Key Violation' durante l'inserimento del secondo record nella tabella dettaglio???
Grazie.

[alka]

Personalmente, trovo abbastanza aberrante suggerire di non usare alcun automatismo sviluppato da persone che sanno quello che fanno (Borland/CodeGear/Embarcadero), che testano le proprie soluzioni con sistemi di qualità e che forniscono un approccio che non richiede di "reinventare la ruota", cosa che invece si fa quando si adottano soluzioni "manuali".

Detto questo, ovviamente, non ha senso abbandonare una soluzione solo perché, volendola utilizzare senza documentarsi preventivamente, si scopre - guarda caso - che sorgono dei problemi.

Per individuare esempi dell'uso di tabelle in master/detail con i componenti TClientDataSet, è sufficiente fare una ricerca.

Io ho trovato questo articolo, tanto per citarne uno, che spiega come creare DataSet nidificati con il componente CDS.

Comunque sia, anche non volendo scomodare questo tipo di soluzione, la correlazione master/detail si può instaurare agendo semplicemente sulle proprietà MasterSource e MasterFields del componente, analogamente a quanto avviene con altre librerie di componenti Delphi specifiche per l'accesso ai dati.

L'errore di Key Violation è invece probabilmente dovuto alla mancata valorizzazione della chiave primaria lato applicazione Delphi.

Chiaramente, senza avere una panoramica particolareggiata del progetto, non è possibile fornire indicazioni più mirate, anche se vale come ho già detto il suggerimento di documentarsi - prima - e sviluppare - poi.

Ciao!

[deleted_29]

Originariamente inviato da alka
Personalmente, trovo abbastanza aberrante suggerire di non usare alcun automatismo sviluppato da persone che sanno quello che fanno (Borland/CodeGear/Embarcadero), che testano le proprie soluzioni con sistemi di qualità e che forniscono un approccio che non richiede di "reinventare la ruota", cosa che invece si fa quando si adottano soluzioni "manuali".

Ognuno ha le sue opinioni.
Personalmente mi fido più di me che di persone di borland/codegear etc, tranne 3 o 4 persone che conosco e di cui mi fido.
Tra l'altro di bug nei codici borland, dal delphi 2 con cui ho iniziato, ne ho trovati un bel po'.

Per quanto mi riguarda, più è "basso" il livello di oggetti che usi, più è facile/immediato sia capire cosa funziona (e cosa no), sia soprattutto portarlo verso altre piattaforme ove gli oggetti "avanzati", magari non ci sono.
E' per me del tutto normale portare in un pomeriggio un progetto da 1.2 milioni di righe da ABS a mysql, per fare un esempio.

Originariamente inviato da it9qbd
Qualcuno ha un progetto di esempio che possa aiutarmi a far lavorare due tabelle master detail con questo componente e che nonostante chiave primaria ed esterna impostati correttamente non mi dia l'errore 'Key Violation' durante l'inserimento del secondo record nella tabella dettaglio???
Grazie.

Fai attenzione che lo "zucchero sintattico", in questo caso, fa sì semplicemente che al momento dell'INSERT nella tabella slave la chiave esterna venga automaticamente impostata.

Se vuoi fare "a mano" (vedi te come ti trovi comodo)

1) niente tabstable, solo tabsquery. sono troppo lente le tabelle (soprattutto in ambito SQL), perchè ti caricano l'intero dataset. Inaccettabile per milioni di righe.

2) fai una procedurina ABSXSQL, che esegue la query (tabsquery,comandosql, flagrichiedilive:boolean=true e roba varia). Ti serve per farne l'overload [se vuoi passare ad altri componenti]

3) diciamo di avere la Tabsquery master e la tabsquery detail
i detail li "refreshi" con un componente tdbedit collegato alla chiave di tabsquery master, evento onchange.

dentro ci metti qualcosa tipo
ABSXSQL(querymaster,"select ... from detail where detail.id='+inttostr(tdbedit(sender).text)...

4) quando inserisci i dati nella detail devi, ovviamente, valorizzare la chiave, con qualcosa tipo (se non usi comandi sql)

with querydetail do
append;
fieldbyname('id').asinteger:=querymaster.fieldbyna me('id').asinteger;
...
resto
...
post;
db.flushbuffers; // questo ti serve con ABS come il pane, db è il componente tabsdatabase


---
Sostanzialmente tieni le query "staccate" e sei tu a decidere quando refreshare le righe della tabella detail (molto utile una variabile del tipo NON_AGGIORNARE, così blocchi il refresh della slave quando non ti interessa, per ragioni di velocità)

Difetti: mah... direi pochi... sono un 4 o 5 righe di codice, una 50 ina in tutto.

Pregi: funziona identicamente con "qualsiasi cosa" che abbia delle Tquery sql, in particolare ZEOS, se vuoi collegarti a firebird, mysql, postgres, sql server e pure oracle

Basta usare cast a tdataset (se preferisci l'approccio edit-post invece di INSERT), presi direttamente dai datasource, e modificare di conseguenza la funzione ABSXSQL.

---
I miei sono solo suggerimenti

[alka]

Originariamente inviato da franzauker
Ognuno ha le sue opinioni.

In merito a questioni che sono opinabili: i fatti, come la matematica, non dipendono dalle opinioni.

Originariamente inviato da franzauker
Personalmente mi fido più di me che di persone di borland/codegear etc, tranne 3 o 4 persone che conosco e di cui mi fido.

Non c'entra nulla la conoscenza o la fiducia nelle persone specifiche.

Dubito fortemente che milioni di sviluppatori Delphi utilizzino il prodotto e i suoi componenti efficacemente solo se conosco di persona qualche persona fidata all'interno della società, che tra l'altro è un pochino distante da noi...

Tutto questo c'entra ben poco con quello che stavo dicendo io.

Originariamente inviato da franzauker
Tra l'altro di bug nei codici borland, dal delphi 2 con cui ho iniziato, ne ho trovati un bel po'.

I bug esistono in qualsiasi software, ed è senz'altro ben più facile introdurli riscrivendo qualcosa di già fatto, soprattutto se funziona bene (magari da più di una decina d'anni), come nel caso del TClientDataSet.

I componenti Delphi sono fatti per essere utilizzati; vi sono bug specifici, ma non si può ricondurre a bug qualsiasi errore riscontrato per mancanza di conoscenza dello strumento, né pretendere di abbandonare preventivamente un approccio solo perché "vi sono stati dei bug", poiché applicando lo stesso principio allora si potrebbe dire che è meglio sviluppare un'applicazione usando direttamente le API di Windows, invece dei componenti VCL, premesso che il compilatore rimane comunque realizzato da un'altra persona... magari si fa in modo di conoscerla direttamente, così da poter usare i suoi prodotti con fiducia.

Scherzi a parte, cerchiamo di rimanere coi piedi per terra, e prima di implementare a mano un sistema "middle tier" valutiamo tecnicamente le soluzioni disponibili.

Originariamente inviato da franzauker
Per quanto mi riguarda, più è "basso" il livello di oggetti che usi, più è facile/immediato sia capire cosa funziona (e cosa no)

La conoscenza del "basso livello" è sempre utile per diagnosticare i problemi approfondendo l'architettura del sistema che si sta utilizzando, e in questo senso Delphi è senz'altro uno degli ambienti più apprezzabili perché coniuga il RAD a un linguaggio e ad una libreria - di cui viene fornito il codice sorgente - che permettono di andare a fondo l'architettura e di inserire, all'occorrenza, elementi nel "cuore" dell'applicazione (es. gestire direttamente i messaggi inseriti in coda da Windows).

Originariamente inviato da franzauker
sia soprattutto portarlo verso altre piattaforme ove gli oggetti "avanzati", magari non ci sono.

In realtà, avviene esattamente il contrario: più si penetra a basso livello, più è difficile realizzare qualcosa di portabile, che invece ad alto livello potrebbe essere tranquillamente supportata poiché il fornitore della libreria o dei componenti può garantire e soprattutto "mascherare" la differenza tra ambienti e piattaforme.

Originariamente inviato da franzauker
xE' per me del tutto normale portare in un pomeriggio un progetto da 1.2 milioni di righe da ABS a mysql, per fare un esempio.

Guarda, non posso affermare il contrario perché ovviamente non ho la possibilità di dimostrarlo, ma non ci credo.


Comunque, in riferimento a quanto detto sopra, è chiaro che vi possono essere casi particolari, o diverse sfumature, o condizioni in cui una soluzione è preferibile rispetto ad un'altra: il vero problema è che, leggendo le tue risposte, sembra che si vada per assolutismi, cioè per assiomi che valgono per qualsiasi caso esistente, e nell'ambito dello sviluppo ben difficilmente ci sono soluzioni o tecniche adattabili a qualsiasi esigenza.

Se le affermazioni fossero accompagnate da una contestualizzazione legata al caso specifico, allora sarebbe diverso, ma se si dice che "una soluzione manuale è sempre preferibile a qualcosa di già sviluppato" senza circostanziare il suggerimento, a me pare inaccettabile, perché è palese che non può essere *sempre* così.

Ciao!

[deleted_29]

Originariamente inviato da alka
In merito a questioni che sono opinabili: i fatti, come la matematica, non dipendono dalle opinioni.

In realtà sia i c.d "fatti", che la matematica, dipendono dalle opinioni, ma questo ci porterebbe lontano.

Dubito fortemente che milioni di sviluppatori Delphi utilizzino il prodotto e i suoi componenti efficacemente solo se conosco di persona qualche persona fidata(...) Tutto questo c'entra ben poco con quello che stavo dicendo io.

A mio parere invece è particolarmente calzante.
Ossia delegare a qualcun altro è un buon modo per... delegare a qualcun altro, sperando (fideisticamente) che sia migliore.
Nel mio piccolo (sarà che sono molto vanitoso, che ti devo dire?) "migliori" di me non ne ho conosciuti poi tanti.

I bug esistono in qualsiasi software, ed è senz'altro ben più facile introdurli riscrivendo qualcosa di già fatto (...)magari si fa in modo di conoscerla direttamente, così da poter usare i suoi prodotti con fiducia.

Che ti devo dire? Io non mi fido di niente e nessuno, me compreso, e se proprio devo farlo... solo di chi veramente trusto

Scherzi a parte, cerchiamo di rimanere coi piedi per terra, e prima di implementare a mano un sistema "middle tier" valutiamo tecnicamente le soluzioni disponibili.

Guarda che non è "a mano", si tratta di usare proprio i componenti standard Delphi e quelli che, nella mia esperienza, trovi in tutti i "pacchetti-db".
Ossia il "minimo-comune-denominatore" che ho trovato in una 15ina di anni nelle varie "librerie", standard, commerciali, open.

In realtà, avviene esattamente il contrario: più si penetra a basso livello, più è difficile realizzare qualcosa di portabile, che invece ad alto livello potrebbe essere tranquillamente supportata poiché il fornitore della libreria o dei componenti può garantire e soprattutto "mascherare" la differenza tra ambienti e piattaforme.

??? "può garantire", intendi nel senso "potrebbe, ma non lo fa mai in concreto"?
E men che meno nel mondo-delphi, dove oggi c'è, domani non più?

il vero problema è che, leggendo le tue risposte, sembra che si vada per assolutismi, cioè per assiomi che valgono per qualsiasi caso esistente, e nell'ambito dello sviluppo ben difficilmente ci sono soluzioni o tecniche adattabili a qualsiasi esigenza.

Se le affermazioni fossero accompagnate da una contestualizzazione legata al caso specifico, allora sarebbe diverso, ma se si dice che "una soluzione manuale è sempre preferibile a qualcosa di già sviluppato" senza circostanziare il suggerimento, a me pare inaccettabile, perché è palese che non può essere *sempre* così.

Ciao!

Se c'è qualcuno di "flessibile" e "anti-visione-tunnel" sono proprio io.
Ho messo il "come" farei, il "perchè".
Volendo incollo pure un pezzo di codice, non so che fare di più.
---
Sintetizzo così: più ci si appoggia a "librerie" di terzi, più è facile che domani la libreria non esista più, non sia più portata e/o allineata, perchè il produttore è fallito, ha venduto, è passato a vb.net... [tutte cose capitate in concreto 1000 volte con delphi]

Il tuo meraviglioso ed elegante programma che si appoggia su un componente-discendente-etc che c'era per delphi X, ora non c'è più per delphi X+1 e tocca "demolire" un bel po' di lavoro, e rifarlo.

Certo, nel mondo ideale tutto ciò non accade, ma nel mondo Delphi (con cui scrivo da quando erano ancora previsti i 16 bit) sono meri (vichiani) corsi e ricorsi storici, un po' come la distruzione di Zion (ci vuole un minimo di alleggerimento )
---
Chi ritiene che i miei suggerimenti non siano validi... non li segua.
Mica m'offendo

[alka]

Originariamente inviato da franzauker
In realtà sia i c.d "fatti", che la matematica, dipendono dalle opinioni, ma questo ci porterebbe lontano.

Diciamo che ci porterebbe a nulla perché quanto dici non è scritto né dimostrato da nessuna parte.

Originariamente inviato da franzauker
Ossia delegare a qualcun altro è un buon modo per... delegare a qualcun altro, sperando (fideisticamente) che sia migliore.

No, delegare serve a sgravarsi dal problema di dover realizzare qualcosa. Poi, nella delega, c'è chi fa il lavoro meglio di altri, e chi lo fa peggio.

Originariamente inviato da franzauker
Nel mio piccolo (sarà che sono molto vanitoso, che ti devo dire?) "migliori" di me non ne ho conosciuti poi tanti.
Che ti devo dire? Io non mi fido di niente e nessuno, me compreso, e se proprio devo farlo... solo di chi veramente trusto

Questo spiega la difficoltà nel discutere di questioni tecniche: se ogni dato tangibile e misurabile, come i fatti e la matematica, diventa una questione di opinione e la validità varia in base alla fede, allora non si potrà mai discutere di nulla.

Originariamente inviato da franzauker
Guarda che non è "a mano", si tratta di usare proprio i componenti standard Delphi e quelli che, nella mia esperienza, trovi in tutti i "pacchetti-db".
Ossia il "minimo-comune-denominatore" che ho trovato in una 15ina di anni nelle varie "librerie", standard, commerciali, open.

E io quando mai ho segnalato cose "non standard"?

Originariamente inviato da franzauker
??? "può garantire", intendi nel senso "potrebbe, ma non lo fa mai in concreto"?
E men che meno nel mondo-delphi, dove oggi c'è, domani non più?

Se c'è una cosa di cui può realmente vantarsi uno sviluppatore Delphi è di poter beneficiare di un linguaggio, di una libreria e di un ambiente di sviluppo che - pur aggiornandosi costantemente alle nuove tecnologie - mantiene una compatibilità all'indietro ineguagliata (tenendo conto che si tratta di un ambiente RAD).

Originariamente inviato da franzauker
Se c'è qualcuno di "flessibile" e "anti-visione-tunnel" sono proprio io.
Ho messo il "come" farei, il "perchè".

Io stavo contestando una tua specifica affermazione, nient'altro.
Poi, non ho mica detto che la soluzione che hai indicato sia errata, nel caso specifico, o che spari a caso, ci mancherebbe.

Originariamente inviato da franzauker
Sintetizzo così: più ci si appoggia a "librerie" di terzi, più è facile che domani la libreria non esista più, non sia più portata e/o allineata, perchè il produttore è fallito, ha venduto, è passato a vb.net... [tutte cose capitate in concreto 1000 volte con delphi]

Questo vale per qualsiasi ambiente di sviluppo o linguaggio: se questo concetto venisse estremizzato, allora oggi staremmo tutti programmando interfacce complesse a finestre con l'assembler.

Infatti, bisogna contestualizzare: qui si parlava di usare un componente di accesso ai dati, quale è il TClientDataSet ad esempio, che esiste da ben più di 10 anni.

Non c'è motivo di essere paranoici, ma piuttosto usare solo un po' di buon senso e valutare correttamente gli strumenti a disposizione.

Originariamente inviato da franzauker
Il tuo meraviglioso ed elegante programma che si appoggia su un componente-discendente-etc che c'era per delphi X, ora non c'è più per delphi X+1 e tocca "demolire" un bel po' di lavoro, e rifarlo.

Non mi pare che le soluzioni da te definite "manuali" non facciano uso di componenti: l'hai detto tu all'inizio. Come mai per questi non si applica il concetto sopra, mentre per tutto il resto sì?

Originariamente inviato da franzauker
Certo, nel mondo ideale tutto ciò non accade, ma nel mondo Delphi (con cui scrivo da quando erano ancora previsti i 16 bit) sono meri (vichiani) corsi e ricorsi storici, un po' come la distruzione di Zion (ci vuole un minimo di alleggerimento )

In realtà, nel mondo ideale e anche pratico tutto ciò accade, e per qualsiasi strumento e/o tecnologia esistente, ben più in altre realtà rispetto a Delphi (si veda l'esempio della fine di VB6 con l'avvento del .NET Framework).

Originariamente inviato da franzauker
Chi ritiene che i miei suggerimenti non siano validi... non li segua.

Questa precisazione è inutile: chiunque ha la libertà di seguirti, che tu lo specifichi e no.

Originariamente inviato da franzauker
Mica m'offendo

E ci mancherebbe altro, visto che nessuno ti insulta.
Però, trattandosi di un forum di discussione, è abbastanza normale che... si discuta.
Se vedi quindi qualcuno che ribatte alle tue affermazioni, non è per offenderti o per evitare che i tuoi suggerimenti vengano seguiti, ma è perché la "fede" nelle questioni tecniche c'entra ben poco ed è normale cercare di apprendere qualcosa discutendone direttamente.

Ciao!