Newsgroup: it.comp.lang.delphi
Titolo: Database aggiornamento lento.

Salve a tutti...
Allora ho questo inghippo (premetto che sono quasi newbie, newbie totale nei
database):
Ho un database (Access) con circa 250-300 records.
Visualizzo alcuni campi (non tutti mi servono) in una Listview pero' facendo
delle operazioni pressoche' su ogni campo , ad esempio alcuni  sono hex e ne
ricavo i dati in Ascii,  in altri il testo che mi serve e' nascosto in una
stringa e quindi uso Copy...ecc.ecc.
E' chiaro che quando devo modificare o cancellare sul database originale
devo fare il percorso inverso, cioe' identificare il record che ha quel
campo xx che in hex corrisponde a yy ecc.ecc.e poi uso  Delete from tabella
where 'campoxx' = 123 epoi rinfresco il listview rifacendogli leggere il
database modificato.
Insomma e' molto lento, specialmente quando devo aggiornare la list view e/o
cancellare diversi record in una sola volta.
Ho pensato a creare una key che identifichi il record sulla mia listview in
maniera che mi dia subito il record da modificare/cancellare sul database
ma.... ci giro intorno senza trovare una soluzione che funzioni.
Qualcuno ha qualche suggerimento per instradarmi sulla via giusta??
Grazie a chi mi vorra' rispondere(spero di essere stato chiaro) e scusate la
prolissita'.
CIAO.

Forse non ho capito bene io ma perché non usi una DBGrid?

 Qualcuno ha qualche suggerimento [...]??
a) usare una dbgrid come suggerito, anche se le operazioni che devi fare
per visualizzare i campi potrebbero rendere pesante la cosa. C'e' pero'
il vantaggio di avere degli eventi apposta cui agganciarsi
(TField.OnGetText)
b) caricare da db all'inizio e poi lavorare *solo* sulla list fino a che
si decida di salvare su db. Consigliabile quando i record sono pochi
come nel caso specifico. Sicuro se sei sotto UPS e se il programma
funziona <g>.
    b1) In questo caso il consiglio e' di caricare in una lista i tuoi
oggetti leggendoli dal db; mettere il listview su virtual (OwnerData) e
gestire gli eventi OnDataXxxx.
    b2) Ovviamente dovrai inventarti un modo per distinguere gli oggetti
cancellati ed i nuovi inseriti che non sono ancora stati salvati su db
(per i secondi dovrai prevedere istruzioni di Insert invece che di
Update, i primi non saranno da mostrare in listview pur essendo ancora
in lista; quest'ultima dovra' possedere proprietà che dicano il numero
di record validi)
c) come b) + periodicamente un thread a bassa priorita' salva le
modifiche su db (o in un formato che ti vada bene, da cui caricare in
caso di crash)
d) come b) ma attraverso un CDS (clientdataset). Non dico altro perche'
non lo conosco abbastanza
Saluti
Paolo Arosio
-- 
"La dimostrazione dell'esistenza di specie intelligenti nell'universo
 e' che non ci vengono a trovare"

 Forse non ho capito bene io ma perché non usi una DBGrid?
Usare una DBGrid è:
1) Molto pesante se i record aumentano,
2) Molto scomodo se vuoi "personalizzare" la visualizzazione,
3) Crea un eccessivo accoppiamento tra logica( Business Rules ) e
presentazione.
Esistendo poi, attualmente, tecnologie in grado di sopperire magnificamente
al
problema degli update lato server( e potendo cmq gestire una logica lato
client a livello di classi che ti facilita il lavoro ), usare un controllo
data-aware è
sostanzialmente inutile.
Giusto come esempio, ti faccio vedere una roba:
Type
    TFieldValue = class( TPersistent )
    public
       property FieldName : String;
       property Value : String;
    end;
    TSqlStatus = ( ss_Unknown,ss_Inserted,ss_Updated,ss_Deleted );
    TSqlObject = class( TPersistent )
    // Usare TPersistent ti consente di registrarne i derivati, dunque anche
creare una struttura a
    // "plug-in" per l'applicazione
    protected
       function GetInsertStatement : String;virtual;abstract;
       function GetUpdateStatement : String;virtual;abstract;
       function GetDeleteStatement : String;virtual;abstract;
       property DataSet : IProviderSupport;
    public
      constructor Create( ADataSet : IProviderSupport );overload;
      procedure Insert;
      procedure Update;
      procedure Delete( WhereClause : String );
      property Status : TSqlStatus read FStatus;
      property StatementParams : TObjectList;
   end;
Ovviamente è stato buttato giu' cosi', potrebbe essere molto migliorato...
ma
rende l'idea di quello che intendo, credo... ^_^
Ciao,
Andrea

sostanzialmente inutile.
Certo, se vuoi farti del male e reinventare la ruota, hai ragione.
-- 
"La velocità luce non è sufficiente Comandante Nunziatella, 
dobbiamo passare alla velocità smodata!"

 Certo, se vuoi farti del male e reinventare la ruota, hai ragione.
Reinventare la ruota?
Dimmi dov'è che la reinvento, perché tra i componenti standard di Delphi una
cosa come quella scritta da me non l'ho mica vista, sai... magari me la sono
persa <g>. E non venirmi a dire che ci sono i componenti data-aware, perché
sai
/benissimo/ che non sono assimilabili a quanto da me scritto.
Vorrei inoltre farti notare - qualora ti fosse sfuggito - che per
"tecnologie in grado di sopperire
magnificamente al problema degli update lato server" mi riferivo al
TClientDataSet.
Ancora non ho capito dove sto reinventando la ruota... sai, ora che ci
penso, quanto
sono stati stupidi i progettisti di delphi! Avevano i componenti data-aware
ed hanno
fatto il Client Dataset... <g>
Ciao,
Andrea

fatto il Client Dataset... <g>
Lasciando perdere il tuo fine sarcasmo, penso seriamente che tu abbia
molta confusione in testa e ti debba ancora confrontare con la vita
*reale* e con database di produzione.


 ha scritto nel messaggio
news:bn5d0s$tcnu3$1...@ID-30644.news.uni-berlin.de...


> 1) Molto pesante se i record aumentano,
Certo che con 20mila record non c'è nulla che tenga e inoltre che li metti a
fare inuna griglia tutti assieme se poi ne visualizzi un migliaio al massimo

presentazione.
Ma che ca...pperi vai dicendo ???!!!  Anche incorporando le Business
Rules mediante strutture specifiche, l'importante è che l'interfaccia
verso la DBGrid sia un TDataSource.  Poi, se si vuol essere del tutto
precisi, bisogna anche dire che Delphi non è lo strumento più adatto
per disaccoppiare le business rules.  Non perché sia Delphi, ma perché
*qualsiasi* strumento "general purpose" come Delphi è debole da questo
punto di vista, IMHO.

Avevano i componenti data-aware ed hanno fatto il Client Dataset... <g>
Quello che hai appena scritto fa capire quanto grande sia la
confusione che hai nella testa.  Dimmi che ca..ppero c'entra il CDS
con i componenti data-aware ! sono due cose ESTREMAMENTE differenti !

Certo che con 20mila record non c'è nulla che tenga 
Di record mostrati in una DBGrid io ne ho visti anche 200mila e non
c'è alcun problema rilevante.  Chiaro, poi, che tutto dipende da cosa
ci fai con 200mila record in una DBGrid, ma sono due problemi diversi:
il primo, se vi fosse, sarebbe un problema tecnico, il secondo è solo
un problema logico.

Io aggiungerei anche che molto probabilemente quello che stai "inventando"
lo ha già inventato qualcun altro solo che non è nei component predefiniti
di Delphi