Newsgroup: it.comp.lang.delphi
Titolo: in memory...replication ?

1. i dati sono in un database SQL: firebird
2. i dati di parecchie tabelle devono essere prelevati e disposti in
4-5 TDBGrid sullo schermo
3. i componenti che popolano le TDBGrid sono IBObjects
4. i dati nelle grid vengono manualmente "massaggiati" dall'operatore
5. i "massaggi" sono roba molto semplice:
- seleziona alcuni record
- cambia alcuni campi
- trascina un record dalla grid A nella grid B
etc
6. a fronte di questi cambiamenti, le TDBGRid devono essere
rinfrescate. La velocita' e' importante
Sembrerebbe una caso tipico per i componenti TClientDataset (che io
non ho mai usato).
a. ci sono controindicazioni ?
b. ci sono soluzioni alternative ?
La soluzione ideale per me sarebbe poter avere 2 database (uno normale
su HD e uno completamente in memoria) con un sistema di replicazione:
non c'e', vero ?
Grazie
Peppe Polpo

Peppe Polpo
	Ciao
	MassimoB
 
---------------------------------
http://www.massimobeschi.it/
---------------------------------
Se tu pagare come dici tu ...
Io lavorare come dico io ...
Se tu pagare come dico io ...
Io lavorare come dici tu ...
---------------------------------

>ti suggerisco di documentarti bene prima di adoperare i ClientDataSet
piu' mi documento, piu' mi sorgono dubbi... :)
Tutto il mio codice e' fatto di stored procedures.
Per inserire un record nella tabella Pippo, io ho una SP fatta cosi':
create procedure InsertIntoPippo(
field1 integer,
field2 varchar(30)
...)
che da Delphi uso cosi':
with TIBOQuery.Create(self) do
try
   DatabaseName:=...
   Sql.Add('execute procedure InsertIntoPippo(:field1, :field2,...)');
   ParamByName('field1').AsInteger:=...
   ParamByName('field2').AsString:=...
   ...
   ExecSQL;
finally
   Free;
end;
Se vedo pippo attraverso un TClientDataset, devo riscrivere tutto come
with clientdatasetPIPPO do
begin
    Insert;
   FieldByName('field1').AsInteger:=...
   FieldByName('field2').AsString:=...
   ...
  Post;
end;
e fin qui poco male.
Pero' la mia "vista sul mondo" e' fatta - sempre mediante una SP - con
una elaborazione non banale fra dati presi da diverse tabelle del
database...
Posso scrivere una query che ritorna una lista di dati ottenuta con
una elaborazione complessa fatta su N TClientdataset ?
Peppe

 una elaborazione complessa fatta su N TClientdataset ?
qui la cosa va chiarita...
il clientdataset è una interfaccia tra la tua app ed un database.
Tale interfaccia viene utilizzata DOPO CHE GLI STATEMENT SQL NECESSARI 
AL RECUPERO DEI DATI SONO STATI ESEGUITI CON LA CONSEGUENTE CREAZIONE DI 
UN CURSORE.
Puoi usare il clientdataset per eseguire query su un db in vari modi, ma 
non puoi eseguire query sql su un clientdataset, nello stesso modo in 
cui se hai 5 oggetti tibquery, tadoquery o tquery non puoi avere una 6 
query che interroga gli altri 5 oggetti query.
AS

Peppe


unidirezionale 
modificare un cursore unidirezionale vuol dire effettuare una modifica
"cosmetica" che non lascia traccia nel database origine, o sbaglio ?
Grazie
Peppe

>>
When using Cached Updates, you simply use one TUpdateSQL component for
each table involved in the join. Therefore, one obvious path to try
when using MIDAS technology would be to set Provider.ResolveToDataset
to true and let the cached update mechanism deal with resolving the
data. Unfortunately, all of the properties and events associated with
cached updates are not used in the MIDAS resolving process, so this
approach will not work.
<<
apparentemente TClientDataset non va per l'applicazione che ho in
mente, ma solo per casi (piuttosto banali) quando la vista sul mondo
si limita a una sola tabella (es: lookup).
Provero' a chiedere nei siti americani se la mia conclusione e'
corretta.
Grazie
Peppe

 "cosmetica" che non lascia traccia nel database origine, o sbaglio ?
Allora...
Immaginiamo di usare una tsqlquery di dbx.Gli metti uno statement sql
del tipo "select * from tabella where campo= valore".
Ora, il cursore restituito da questo oggetto è di tipo forward-only,
ovvero, non puoi usare metodi che spostino il puntatore dal record
attivo ad un record PRECEDENTE a quello attivo.
Avendo questa limitazione tu non puoi ad esempio mostrare DIRETTAMENTE
il risultato della tua select in una dbgrid; per contro, se devi
ciclare sui records con un while not query.Eof... questo cursore è
molto + veloce di un cursore bidirezionale.
Quindi, come kakkio fai a mostrare i dati in una dbgrid? Semplice...
1) metti sul datamodule  un tdatasetprovider alla cui property dataset
associ la query di cui parlavamo prima.
2) metti un TClientdataset sul datamodule alla cui property
DatasetProvider associ il tdatasetprovider creato al punto precedente
3) associ il tclientdataset ad un datasource che sarà poi associato
alla dbgrid.
4) infine, invece di assegnare lo statement sql alla tsqlquery lo metti
nella commandtext del tclientdataset, avendo cura di aggiungere nelle
options del tdatasetprovider l'elemento allowchangestatement o roba
simile (mo mi sfugge il nome...)
Usato in questo modo, il clientdataset diventa una cache locale e
bidirezionale del cursore restituito dal server.
Inoltre, quello che sta "dietro" il tdatasetprovider diventa totalmente
passivo e può quindi essere sostituito con relativa facilità.
Infine, il tdatasetprovider potrebbe non far parte della app che lo
usa...
La prop exported, se messa a true, permette ad una app di collegare ad
un tclientdataset un tdatasetprovider esposto da un server dcom o
corba...
AS

Grazie
