Newsgroup: it.comp.lang.delphi
Titolo: Trovare solo l'esistenza di un record in un clientdataset

E' possibile cercare un record con dei campi chiave senza far spostare un
cursore?
mi spiego meglio:
ho un clientdataset collegato ad una tabella di firebird.
Quando l'utente apre il clientdataset si posiziona su un nuovo record e
incomincia ad inserire i dati. In quel momento vorrei controllare se nel
dataset esiste un record con chiave uguale oppure no però senza spostarmi
come fa il metodo locate.
Come posso fare?
Ciao
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 Come posso fare?
Usi un secondo dataset o query per la ricerca ....
Giulio 

Giulio 
Ho avuto lo stesso problema pochi giorni fa e credo che
la tua soluzione vada bene se ad ogni qualsiasi
modifica di record sul ClientDataSet chiami
l'ApplyUpdates ma se non lo fai e aggiorni il database
solo alla fine di tutte le operazioni (logica
disconnessa) allora la soluzione proposta non va bene
in quanto l'utente puň aver immesso dei record senza
che il db lo sappia. 
Ora i problemi da analizzare sono due:
1) Il record ha una chiave primaria generata dal db.
2) Il record ha una chiave primaria dedotta dai dati
inseriti.
Nel caso (1) sei quasi fregato :( mentre nel caso (2)
io ho risolto in questa maniera:
prima di andare in edit o insert ti salvi in una lista
i vallori della chiave facendo un merge fra quello che
č presente sul db e quello che trovi nel ClientDataSet
poi quando devi fare la verifica la fai sulla lista
opportunamente creata e vai tranquillo.
Altra soluzione piů veloce, ma che si puň applicare
solo se il ClientDataSet ha tutti i records su cui vuoi
eseguire il controllo, crei uno stream in memoria che
prima dell'edit o dell'insert carichi con un
SaveToStream del ClientDataSet su cui stai lavorando,
poi ti crei un ClientDataSet di controllo e lo carichi
con un LoadFromStream dello stream temporaneo
preventivamente caricato, poi vai in edit o in insert
ed il controllo lo fai sul ClientDataSet di controllo,
appunto. ;)
Insomma il gioco sta nel crearsi un clone del dataset
che vuoi mantenere fermo su un record ... ovviamente
iltutto a discapito dello spazio in memoria e del tempo
che ci si mette a creare il clone.
Spero di essere stato chiaro.
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 ...
---------------------------------

MassimoB ha scritto:
<super cut>
Taglio tutto solo per chiedere una cosa: per quale motivo si ha
questa esigenza?
L'OP chiedeva:
<inizio cit.>
ho un clientdataset collegato ad una tabella di firebird.
Quando l'utente apre il clientdataset si posiziona su un nuovo record e
incomincia ad inserire i dati. In quel momento vorrei controllare se nel
dataset esiste un record con chiave uguale oppure no però senza spostarmi
come fa il metodo locate.
<fine cit.>
Questa affermazione mi fa nascere diverse domande (probabilmente dovute
alla mia scarsa dimestichezza con i DB): se qualcuno ha la pazienza di
chiarirmi questi dubbi ...
1) Verificare se esiste un record con chiave uguale: ma non e' compito del
DB generare chiavi univoche per ogni nuovo record inserito (trigger e
compagnia bella)?
2) Il metodo Locate sposta il cursore: i bookmark e i metodi
disable/enable control non posso sopperire a questa "lacuna"?
3) Fare controlli simili su architetture client/server (nel caso specifico
firebird) e magari multiutente non e' concettualmente sbagliato?
Forse non ho capito bene il senso del discorso - in tal caso daro' la
colpa alla cattiva digestione :-) - ma qualcosa non mi e' chiaro.
Ciao
ACSH
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

ACSH


 compagnia bella)?
Quasi sempre sì, e comunque si può anche creare un indice unico su un campo
qualsiasi (per cui l'inserimento di un "doppione" genererebbe un'errore da
parte del DB).


 inserito il codice come primo dato?".
Non sarebbe allora meglio: l'utente inserisce il dato che deve essere
univoco (che sia poi la chiave primaria o meno non importa) in un edit
NON dataaware, il programma esegue una query sui dati (o una locate
sul CDS) per verificare che non esista gia' tale dato. Se esiste,
allora visualizza una bella dialog con la scritta "Record gia'
esistente"
mostrando i dati e magari permettendone la modifica, altrimenti
mostra un'altra bella dialog "Record inesistente. Vuoi aggiungere
altri dati?", aprendo al suo eventuale Si' una maschera per
l'inserimento degli altri dati.
Tutto questo, mettendo il CDS in stato di edit solo quando e' davvero
necessario, senza ritrovarsi nella spiacevole situazione dell'OP di
dover scorrere il CDS quando non e' consentito.
Ciao
ACSH

 parte del DB).
Ma quindi si lavora sempre su lato Server (scusa la mia poca dimestichezza
con i termini sull'argomento sul quale discutiamo). Cioe', il succo del
mio discorso e' questo: lasciamo fare al motore del DB quello che sa fare
meglio, cioe' la gestione delle chiavi, lasciando all'utente la sola
preoccupazione di usare al meglio il programma da noi sviluppato - mi sa
che ho preso una traettoria che ci portera' fuori strada se non la finiamo
subito ...
Ah, ben ritrovato: non sparire subito, pero'!


 sul CDS) per verificare che non esista gia' tale dato.
Operazioni di "verifica esistenza" lanciate da un client in un contesto
multiutente (considera alle applicazioni con 50/60 utenti contemporanei)
non hanno molto senso.  Considera un utente che verifica se il record
esiste, non esiste, apre la maschera e comincia a inserire i dati; si
prende un caffé e resta via 20 minuti.  Le applicazioni client/server in
un contesto multiutente dovrebbero sempre lavorare in modo ottimistico.


 firebird) e magari multiutente non e' concettualmente sbagliato?
Dipende dalla logica dell'applicazione.
Concettualmente, soprattutto se si parla di logica disconnessa, il 
controllo *definitivo* deve essere fatto necessariamente nell'istante in 
cui si applicano le modifiche. In questo caso dovrebbe essere il server 
a gestire eventuali problemi di chiave duplicata, ecc.
Naturalmente è possibile anche implementare un controllo a monte, 
durante l'immissione dati da parte dell'utente, ma questo sarà valido 
solo per la "fotografia" di dati su cui sta lavorando in quel momento, 
quindi è utile per dare un primo feedback all'utente, ma sicuramente non 
necessario.
Ciao,
Gianluca.


Be', a quel punto dovrebbe intervenire il suo capo, non il mio 
programma.
;-)
Grazie a tutti per le spiegazioni, mi avete "quasi" convinto.
Ciao
ACSH

 piacevoli [...]
Ah be', questa è un'idea che ho abbandonato da tempo (diciamo che non me
la sono mai fatta venire).  In quanto all'utente, io sono per il caro,
vecchio, terminale a caratteri.  Ovvero quando digitare al computer
significava lavorare e basta.


 Ah, ben ritrovato: non sparire subito, pero'!
Grazie, ma questo non lo posso garantire (impegni di lavoro, purtroppo) :-)
