Newsgroup: it.comp.lang.visual-basic
Titolo: [SQL] UPDATE e INSERT o DELETE e INSERT ?

Salve a tutti,
in una ListView ho le seguenti due situazioni:
1- es. al caricamento 5 righe, ne aggiungo 2 alla ListView
per l'UPDATE posso eseguire:
1.1 - UPDATE delle 5 righe iniziali e inserimento delle 2 nuove
1.2- DELETE delle 5 righe iniziali e inserimento delle 7 righe presenti
nella ListView.
L'identificativo del record non è in relazione con nessuno
Quale metodo di solito adottate ?
2- es. al caricamento 5 righe, ne elimino 2 dalla ListView
ragionamento come sopra
Grazie
giuseppeD


io generalmente faccio DELETE e INSERT, lo trovo piu' pulito e meno a
rischio di errori soprattutto se si usa un programma in rete (se si fa un
UPDATE su un record che non esiste devi gestire l'errore mentre il DELETE
non fa niente)
inoltre per sapere se una riga e' cambiata devi fare un sacco di confronti
(ovviamente a seconda di quanti valori possono cambiare)
Luca

[GiuseppeD = 
circa_NoSpam_...@tin.it
 in
HGfcc.23075$
rM4.1...@news4.tin.it
] ha scritto:

Io adotto un sistema solo: faccio una cosa sola, nel momento in cui avviene.
Aggiungo una riga? La aggiungo nel database.
Elimino una riga? La elimino dal database.
Modifico? La modifico sul database.
"L'identificativo del record non è in relazione con nessuno"?
Non capisco... Manca un riferimento al record?
E come fai a dire "Update delle 5 righe iniziali" se non le conosci in modo
preciso?

 preciso?
credo intenda dire che gli ID dei record usati nella ListView non vengono
usati per relazioni con altre tabelle

 usati per relazioni con altre tabelle
Carico la Lista con un idcategoria e Path/nomefile.estensione
Per un idcategoria posso caricare piů path
al Add sulla ListView verifico se il path č presente.
Quindi se carico, nella Lista, un idcategoria con 5 path,
se l'operatore aggiunge altri due path, che non posso salvare al momente
dell'Add,
mi trovo gestire 5 record vecchi e due nuovi.
per i 5 vecchi utilizzo l'accoppiata idcategoria + path, per l'UPDATE,
ma anche per i nuovi, l'inserimento č l'accoppiata idcategoria + path.
Dovendo eseguire il tutto a fine operazione č meglio cancellare i 5 presenti
in tabella,
e inserire i 7 record presenti nella ListView, con una Transazione, come
suggerito da Luke;
o UPDATE per i 5 record vecchi e INSERT solo per i due nuovi ?
Ave
giuseppeD

 o UPDATE per i 5 record vecchi e INSERT solo per i due nuovi ?
Beh, visto come la metti, i problemi sono due, secondo me da gestire
separatamente, record per record o con due comandi SQL: l'update delle
informazioni esistenti + l'aggiunta delle nuove e l'eliminazione delle
vecchie.
Personalmente, sempre costretto dalle tue imposizioni, looperei fra le
chiavi (non necessariamente la Key) della ListView e, per non saper nè
leggere nè scrivere, ne verificherei l'esistenza. Se esiste e se il caso,
farei l'aggiornamento, se non esiste la aggiungo. Poi looperei fra le chiavi
del database e eliminerei quelle che non esistono nel listview.
Se fossi libero, farei le cose nel momento in cui avvengono. Non desidero
insistere, ma mi cito, stavolta al contrario, ma il concetto non cambia:
qual è la sostanziale differenza fra il disporre di un'informazione a un
secondo di distanza dalla precedente o a un anno (si fa per dire) di
distanza? La mia risposta è sempre la stessa: nessuna. Per chiarire: anche
se tu riuscissi a far tutto con un singolo comando SQL, esisterebbe sempre
la possibilità che un'altra postazione trovi una situazione parziale, non
corrispondente alla realtà finale, anche se questa diventasse vera un
secondo (o un anno) dopo.

 secondo (o un anno) dopo.
In questo caso non ho conflitto di multiutenza
Ave
giuseppeD

 In questo caso non ho conflitto di multiutenza
... a maggior ragione... sempre IMHO

ragionamento come sopra
Questo e' ancora piu' semplice: DELETE FROM xxx WHERE ID = 1111 OR ID
= 222. Qui e' un'operazione unica, per cui la transazione non serve.
Il principio di base  - che anche a me e' stato insegnato, ell'epoca -
e': se c'e' un sistema efficiente per fare una cosa su un database,
non ti affannare a reinventare l'acqua calda! Nota che ovviamente la
cosa si applica soprattutto quando si parla di DBMS.
Ciao!
Luca