Newsgroup: it.comp.lang.delphi
Titolo: Stored Procedure e Componenti DataAware

Ciao a tutti,
generalmente non faccio un grande uso di Stored Procedure, anzi... Però sto 
facendo un pò di prove e piu' che altro mi interessano i pareri di chi ha 
già dovuto affrontare situazioni del genere.
Supponiamo di avere un database (MS SQL Server nel dettaglio, ma la cosa è 
valida anche per altri RDBMS equiparabili) e di non poter accedere 
direttamente alle singole tabelle ma:
- per estrarre i dati avere a disposizione specifiche view;
- poter manipolare i dati solo attraverso l'esecuzione di specifiche Stored 
Procedure di inserimento, modifica, eliminazione dati.
Il mio dubbio è piu' che altro legato all'implementazione dell'interfaccia 
Utente ed eventualmente all'uso dei controlli DataAware.
Mi sono posto due casi, diciamo per accedere ad una tabella:
1. ho una maschera con la griglia e quindi l'elenco dei record ed una 
maschera per la gestione del dettaglio del singolo record;
2. ho una maschera con griglia e vorrei editare direttamente in quella.
Dal punto di vista dei componenti quindi, immagino, vado ad utilizzare un 
TADODataSet (per via di MS SQL Server) per popolare la griglia, mentre poi 
devo definirmi tre TADOStoredProc per Insert, Update e Delete associati 
appunto alle rispettive stored procedure.
Ora, il caso 1. mi sembra abbastanza semplice da gestire: popolo la griglia 
(TDBGrid) attraverso la view, in relazione ai tasti premuti posso chiamare 
la stored di delete ed aggiornare i dati, oppure aprire la maschera di 
inserimento/modifica *non* dotata di controlli DataAware; all'atto del 
salvataggio, in relazione al trovarmi in inserimento/modifica, valorizzo 
tutti i parametri della stored piu' indicata e la eseguo. Qui credo di 
comportarmi correttamente.
Nel caso 2., invece, vorrei capire se è possibile attivare la funzionalità 
di editazione dei dati direttametne nella TDBGrid utilizzando comunque le 
stored procedure di cui sopra.... ....
Una soluzione, ma riporta un pò al caso 1, è quella di aggiungere sotto la 
griglia una serie di controlli DataAwareless (!!!!??! :-D ) per gestire 
l'inserimento e la modifica dei dati sempre tramite Stored Procedure.
Ma se volessi a tutti gli effetti continuare a digitare nella mia TDBGrid? 
...
Beh... l'unica idea che mi viene in mente è:
- mantengo la possibilità di editing tramite le options della TDBGrid;
- quando l'utente attiva la modifica o l'inserimento di nuovo record lascio 
tutto com'è ovvero lascio che la grid si comporti come suo standard 
previsto;
- intercetto l'evento BeforePost sulla vista e prelevo tutti i campi nuovi, 
li passo alla stored di inserimento o modifica e la eseguo. Di seguito, 
tramite Abort interrompo il post sulla vista ed effettuo il refresh dei 
dati.
Ho fatto una piccola prova e mi sembra che così tutto funzioni, ma.... ... 
piu' che una soluzione tecnica mi sembra di aver messo insieme, come si dice 
dalle mie parti, una scarpa ed uno zoccolo.
Quindi, a questo punto, chiedo pareri in merito.
Gianluca. 

> 2. ho una maschera con griglia e vorrei editare direttamente in quella.
Puoi considerare l'ipotesi di utilizzare i componenti TClientDataset per
gestire il secondo caso: tramite la query effettuata sulla stored procedure
riempi il ClientDataset, che da ora in avanti contiene dati completamente
slegati dal database; una volta completata l'operazione di aggiornamento di
un singolo record sul cds, "mappi" le modifiche sulle tabelle
corrispondenti. Questa cosa che mi è venuta in mente somiglia molto a
quella proposta da te, ma evita di dover innescare il comportamento di
default in seguito alla Post per poi abortirlo prima della sua esecuzione
effettiva.
Sappimi dire. Saluti
 
	Marco Bortolani
	info @ 
marcobortolani.it

Come suggerito, puoi usare in ClientDataset, ma io ti suggerisco di 
usarlo collegato ad un TDataSetProvider. Nell'evento BeforeUpdateRecord 
di quest'ultimo puoi sapere di che modifica si tratta 
(insert/update/delete) ed invocare la stored procedure appropriata. 
Restituendo Applied = True informi il provider che hai già provveduto ad 
applicare le modifiche, e che non deve effettuare alcuna ulteriore 
operazione.
Un'altra soluzione se il dataset che usi supporta le cached updates è di 
usare queste con un componente TUpdateSQL che invoca le stored procedure.
Non ho mai usato molto ADO, ma è possibile che qualche evento del 
componente possa essere usato direttamente per fare quanto sopra.
Luigi D. Sandon - D&amp;D Support Team
--- posted by geoForum on 
http://www.delphiedintorni.it

Riguardo le stored procedure, hanno come tutti gli strumenti i loro 
pregi e difetti.
Il primo vantaggio è che, se devi elaborare una considerevole mole di 
dati, essendo una stored procedure eseguita lato server hai un guadagno 
di performance in quanto eviti un bel po di traffico di rete.
Il secondo vantaggio è che, essendo parte integrante del db, una loro 
fix a seguito di errori riscontrati dagli utenti è centralizzata e non 
implica dover compilare nuove versioni di applicazioni etc; nel peggiore 
dei casi, basta che gli utenti escano della app in modo che l'update non 
vada in conflitto se vi sono tabelle in uso.
Il rovescio della medaglia?? ehehehehehe!
Una stored procedure che deve processare un bel po di dati potrebbe 
richiedere un bel po di risorse di sistema, compreso tempo cpu, cosa che 
potrebbe ripercuotersi sulle performance globali del sistema...
Inoltre, essendoci non poche differenze tra i dialetti sql supportati 
dai vari db, corri il rischio di basare la logica della elaborazione su 
costrutti che potrebbero non esistere su altri db.
Infine, ti trovi la logica della app divisa in due entità 
(app+database), una cosa sulla quale occorre riflettere...
Per la cronaca, se lavori in MDA (vedi il modello eco di d8 e 
c#builder...), l'uso delle stored procedure è quasi vietato, visto che 
MDA impone al db un ruolo di semplice storage, mettendo la logica 
completamente nella applicazione.
Da come la poni tu, replichi quello che i componenti di accesso ai dati 
fanno già in automatico, o sbaglio?
AS

 fanno già in automatico, o sbaglio?
Non proprio.
L'idea alla base nasce da un gestionale che ho visto; sviluppato in VB 6.0 e 
database MS SQL Server.
Per come è strutturato, non è possibile accedere direttamente ad alcuna 
tabella, ma è sempre necessario passare per stored procedure e view.
Quindi mi ritrovo con:
- una o piu' viste per l'interrogazione dei dati;
- una stored per l'immissione di un nuovo record;
- una stored per la modifica di un record;
- una stored per la cancellazione di un record.
Naturalmente tutta la business logic è implementata nel database, tanto che, 
provato e confermato, è possibile gestire tutto quanto direttamente da 
SQLProfiler.
Le form che ho visto in VB... solo logica di formattazione dei dati. L'unica 
cosa un pò "pesante" da implementare erano le routine che trasferivano i 
dati dai parametri delle stored ai campi sulle form e viceversa. Piu' un pò 
di codice qua e la' per implementare enabled/disabled su alcuni controlli.
Come esempio, una stored procedure permetteva di immettere il dettaglio 
articolo in una fattura: effettuava tutti i controlli del caso e 
successivamente immetteva un nuovo record e ricalcolava il totale fattura al 
volo. Idem le stored di eliminazione di una riga di dettaglio e quelle di 
aggiornamento.
Ora, se ragioniamo nella logica di avere un'applicazione che si adatta a 
qualunque database, questa politica è fallimentare perchè comunque si 
incorre in tutti problemi che hai citato. Ma se ragioniamo in una logica 
dove sostanzialmente vogliamo dare un'interfaccia dal database (che a questo 
punto è divantato l'applicazione vera e propria) a qualsiai applicazione, 
senza correre il rischio che un qualunque modulo sviluppato da un chicchesia 
vada in qualche modo ad influire sulla integrità dei dati, mi sembra una 
soluzione veramente molto elegante.
Infatti virtualmente qualsiasi applicazione potrebbe accedere al database e 
quindi potremmo considerarlo "aperto", ma allo stesso non ci sarebbe la 
necessità di documentarne il contenuto e la struttura, ma solo 
l'interfaccia.
Quindi, passando da un ambiente tipo VB dove il concetto di DataAware è 
abbastanza indecente, a Delphi, mi chiedevo come poter fare per implementare 
una logica del genere, soprattutto immaginando di lavorare su una TDBGrid, 
dove mi piacerebbe poter mantenere l'editing direttamente in griglia. La 
scelta della TDBGrid è principalmente dovuta alle semplificazioni che avrei 
a livello di formattazione dei dati (riempire manualmente una TStringGrid mi 
sembrerebbe da folli) ed al fatto che restando legata ad una view sarebbe 
più semplice sfruttare direttamente gli oggetti Fields.
In ADO .Net esiste appunto l'oggetto DataAdapter il quale espone quattro 
command (select, insert, update e delete) che potrebbero naturalemente 
essere stored procedure. Invocando l'Update, nell'effettuare la 
sincronizzazione con il Database fisico, decide quali comandi utilizzare.
Piu' o meno mi sembra che una logica del genere sia insita dell'oggeo 
TUpdateSQL ma quest'ultimo è un componente BDE ed io vorrei poter utilizzare 
i componenti ADO.
Gianluca. 

 utilizzare i componenti ADO.
Usa gli ADODataset per leggere/scrivere da DB, i TDatasetProvider
agganciati a questi per , e quindi i TClientDataset agganciati ai
provider. I controlli dataware fanno riferimento ai TClientDataset. Quando
chiami TClientDataset.Apply le modifiche vengono inviate al provider per
essere applicate al DB.
Lo schema è TAdoDataset <-> TDatasetProvider <-> TClientDataset <->
TDatasource <-> Controlli DB Aware.


TDatasource <-> Controlli DB Aware.
Perfetto, chiaro e comprensibile.
:)
ciao
-- 
Morde. 
(
mo...@despammed.com
)
M-List di icld: 
http://it.groups.yahoo.com/group/icld/

Però in MDA hai la logica nella app, e se devi fare debug, puoi 
sfruttare tuti gli strumenti di debug offerti dall'ambiente di sviluppo, 
cosa che è indubbiamente comoda.
Se hai tutta la logica nel db, va da se che è *fondamentale* che il db 
abbia, oltre a un dialetto sql bello tosto, strumenti di debug avanzati, 
altrimenti prevedo un escalation del consumo di stupefacenti da parte 
degli addetti a questo lavoro.... ;)
AS



Ho cominciato da una settimana a sviluppare (vabbè, in VB... lasciamo 
perdere come funzionano le TrueDBGrid, con quello che le hanno pagate) 
un'applicazione di questo tipo dove è imperativo effettuare tutte le 
operazioni tramite stored procedure.
A tutti gli effetti la sto trovando un'esperienza abbastanza interessante.
Effettivamente il Debug è piuttosto difficile, però devo anche considere una 
cosa: il codice che scrivo nelle stored per aggiornare set di record è in 
quantità molto inferiore rispetto allo stesso che scriverei in VB (tenuto 
conto appunto che è VB e non Delphi, ma anche con Delphi sarebbe un pò di 
piu') ed allo stesso tempo proprio il fatto di poter gestire comandi SQL 
"secchi" semplifica molto il lavoro... naturalmente quando una stored 
comincia a raggiungere le cento righe di codice diventa ingestibile.
Il debug: ad oggi con SQL Server l'errore viene riportato sotto forma di 
eccezione con l'indicazione della riga in cui è verificato, quindi è 
abbastanza immediato. Avendo inoltre a disposizione strumenti come il 
Profiler o Query Analizer è possibile vedere esattamente cosa accade quando 
l'applicazione richiama le procedue o fa scattare i vari trigger; quindi poi 
isolare l'errore è abbastanza semplice.
Ma nel tempo, aumentando anche la complessità delle cose da fare, saprò 
sicuramente fornire maggiori dettagli. ;-)
Gianluca.

 eccezione con l'indicazione della riga in cui è verificato, quindi è 
Identico a ib60.. :(
Bye
AS

 bel linguaggio?
Senza dubbio. Infatti ad oggi ho deciso di approfondire (ma è anche una 
questione di qualità delle risorse disponibili) proprio C#. Dopo aver visto 
un pò di Delphi 8, ho deciso di aver fiducia nella prossima versione...
Sul fatto che 
vb.net
 non abbia futuro: prova a prendere in considerazione 
quanti "programmatori" VB ci sono in giro. Ne ho visti alcuni *non* riuscire 
a comprendere i paradigmi di Delphi, non oso immaginare la fatica che 
potrebbero fare a passare a C#. Non sia mai detto che si cominci a fare un 
pò di "selezione naturale".
Gianluca.

 C#.
Recentemente, ho cercato di aiutarne qualcuno su qualche forum (che 
tribolava su 
VB.NET
 arrivando da VB6) basandomi sulle conoscenze 
acquisite del framework e del linguaggio C#... citando alcune parole 
come /istanza/ e /metodo/ sono stato "bollato" come saccentone e 
criticato, perciò ho dovuto lasciar perdere per evitare arrabbiature nel 
tentativo di aiutare qualcun altro, per giunta. :-D
-- 
Marco «Alka» Breveglieri
  ABLS Team S.n.c. - Software & Web
  Via De Gasperi, 14
  42019 Scandiano (Reggio Emilia)
 
http://www.abls.it

tentativo di aiutare qualcun altro, per giunta. :-D
Per favore passami il link del forum (anche in privato), ho voglia di
"mordere" qualche polpaccio ;-)


Gianluca, ti ho scritto una mail.
AS

 Gianluca, ti ho scritto una mail.
Lo so ;-)