Newsgroup: it.comp.lang.delphi
Titolo: Trigger con ClientDataSet no con Insert si con InsertInto

dopo le indicazioni ricevute , ho fatto delle prove con
ClientDataSet , ma scopro che non mi cattura i Trigger.
in pratica , in una Tabella del Db , ho creto Generatore e
Trigger per avere un campo autoincrementale.
SqlConnection=<nome db>
SqlDataSet1->SqlConnection1
ClientDataSet1->DataSetProvider1
DataSetProvider1->SqlDatSet1
DatSource1.DataSet->ClientDataSet1
se faccio ClientDataSet1.Insert il campo autoincrementale
resta vuoto
se invece a SqlDataSet1.Camandtext assegno
 una query del tipo Insert Into ed eseguo ExecSQL
il Trigger legato al campo incrementale viene eseguito.
come posso attivare il Trigger su ClentDataSet1.Insert ?

dato che il Trigger non mi prende il Valore del
campo da incrementare , ho creato una StoredProcedure
1) Ho eliminato il Trigger
2) Creato la StoredProcedure (SQLStoredProcedure),
legata al Generatore
3) Nell'evento AfterInsert del ClientDataSet ho
inserito:
 SQLStoredProc1.ExecProc;
 ClientDataSet1['CONTATORE']:=SQLStoredProc1.Params[0].Value;
cosi' il campo incrementale funziona, al comando ClientDataSet.Insert
se ho sbagliato, datemi delle indicazioni. 

 come posso attivare il Trigger su ClentDataSet1.Insert ?
Dunque, quando fai ClientDataset.Insert č corretto che il campo
autoincrementale resti vuoto, a meno che tu abbia una definizione dei
campi persistente nel CDS. Questo perché la "insert" del CDS *non č*
l'istruzione "Insert into" di SQL ma č piů simile alla Insert di una
TTable. Quando poi vai a fare la ClientDataset.ApplyUpdates sul
DataSetProvider, esso dovrebbe trasformare quella Insert in una INSERT
INTO e quindi scattare il trigger.
Hai provato cosě?
Ciao,
Andrea

Ancora un dubbio,
dopo aver eseguito il Post del ClientDataSet , eseguo 
ClientDataSet1.ApplyUpdates(-1)
che invia i dati pe rla scrittura al DataSetPrivider.
Pero' non ho piu' Transazioni attive come nel caso di una Query.
Mi chiedo se sarebbe meglio dopo un ClientDataSet.Insert ,invece che chimare 
il Post
esegure una Query di aggiornamento , del tipo.
UPDATE <Tabella> SET Campo1=:Campo1, Campo2=:Campo2
WHERE Campo1=<ValoreCambiato
e chiamare ExecSQL. da BeforeUpdateRecord del DataSetProvider

e chiamare ExecSQL. da BeforeUpdateRecord del DataSetProvider
è esattamente quello che succede dietro le quinte del
terzetto Dataset->DatasetProvider->ClientDataset e ti
dirò di più, ogni volta che il terzetto esegue una
modifica o cancellazione di dati esistenti esegue
anche un controllo per un'eventuale necessità di
riconciliazione dei dati modificati, nel frattempo, per
esempio, da qualche altro utente (ottica fortemente
ClientServer). Fai fare a loro e fidati (ovviamente
dipo esserti documentato adeguatamente a riguardo ;) ).
Se li utilizzi correttamente in un ottica applicativa
standard (senza logiche troppo fantasiose) ti
ritroverai a scrivere praticamente solo la select
iniziale in SQL ... :) ...
	Ciao
	MassimoB
 
---------------------------
http://www.massimobeschi.it/

 e chiamare ExecSQL. da BeforeUpdateRecord del DataSetProvider
No, non è meglio: è sbagliato.  Il Post lo devi eseguire non deve
importarti che ci siano transazioni attive, anzi, che non ci siano
transazioni attive e che quella necessaria si attivi solo per il tempo
necessario alla modifica è una cosa positiva.  Devi separare nettamente la
logica client da quella server.  Le query dirette ti serve farle solo
nell'OnBeforeUpdateRecord.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

i vostri consigli , mi hanno fatto capire che la logica lato Client e' molto
simile a quella gestita dal Bde, con Insert,Edit,Post.
dopo alcuni inserimenti , soliti Test1,Test2.... sia dal PcClient che dal
PcServer (non dedicato) , se non esegue una query di refresh , i dati
inseriti , pur essendo nel DataBase , non sono visibili , con i soliti
Prior,Next sul Cds.
ora pero' , come avevo gia segnalato , i Trigger non funzionano , ma si
deve usare una StoredProcedure per ottenere un Contatore automatico
al momento del *Insert* .
niente di strano , ma questo mi obbliga ad avere 2 dll
- dxexpint.dll
- midas.dll
e quest'ultima mi , pare di avere letto in qualce post del ng. che sia
soggetta a royalty. 

 - midas.dll
Nessuno ti *obbliga* ad avere queste DLL se usi il ClientDataSet.
La prima è legata a DBExpress, MIDAS.DLL non è più soggetta a royalties e,
se non vuoi portartela dietro come DLL, puoi usarla come unit compilata:
MidasLib.dcu.



la logica C/S mi dice che lavoro su un set di dati necessario in un
dato momento , quindi una SQL preleva cio' di cui si ha bisogno.
mettiamo che si siano prelevate le citta' con inziale E
se inserisco altre citta con iniziale E , fino a quando non eseguo una
query che preleva quelle aventi E per iniziale , le nuove inserite non
saranno visibili al CDS.
forse io non capisco ma
CDS dipende da DSP
DSP dipende da SqlDataSet
come puo CDS vedere cio' che ancora non e' presente nel SqlDS. 

 saranno visibili al CDS.
Forse c'č qualcosa che mi sfugge, ma a me sembra ovvio e corretto.
I dati che un utente vede sono sempre e solo un riflesso temporaneo di una
parte della base dati.  Qualunque operazione un utente compie va comunque
"validata" su ciň che č presente in base dati al momento dell'operazione. 
Se non fosse cosě, non funzionerebbe nessun software gestionale in
circolazione.
