Newsgroup: it.comp.lang.visual-basic
Titolo: Eliminazione record tabella con chiave primaria

Ciao a tutti provo ad inoltrare nuovamente il quesito, magari è sfuggito ed
io non so proprio come risolverlo,
ho la necessità di usare un collegamento ad un dataenvironment in un form
del mio programma.
Questo DE è collegato ad una tabella di Access. Tramite alcuni comandi è
possibile aggiungere, modificare ed eliminare dati di una tabella.
Tutto funzionava correttamente finchè non ho modificato la struttura della
tabella aggiungendo un campo ID di tipo contatore con chiave primaria.
Il problema nasce quando dopo aver creato un record, nella stessa sessione
senza chiudere il programma, lancio il comando per eliminarlo. Appare
infatti il messaggio "Impossibile individuare la riga specificata per
l'aggiornamento. E' possibile che alcuni valori siano stati modificati dopo
l'ultima operazione di lettura".
Questo problema è nato solo dopo l'inserimento del campo ID.
Il codice per l'aggiunta di un record è:
 DataEnvironment1.rsTRg.AddNew
 DataEnvironment1.rsTRg("Nome").value = lblCodice.Caption
 DataEnvironment1.rsTRg("Giorno").value = Format$(Calendar1.value,
"dd/MM/yyyy")
 DataEnvironment1.rsTRg("CodComm").value = DataCombo1.Text
 DataEnvironment1.rsTRg("Tempo").value = txtTempo.Text
 DataEnvironment1.rsTRg.Update
Il codice per l'eliminazione di un record è:
DataEnvironment1.rsTRg.Delete
DataEnvironment1.rsTRg.Filter = "Professionista = '" & lblCodice.Caption &
"' and Giorno = #" & mbGiorno.Text & "#"
If DataEnvironment1.rsTRg.BOF = True Or DataEnvironment1.rsTRg.EOF = True
Then
cmdElimina.Enabled = False
Else: cmdElimina.Enabled = True
End If
If DataEnvironment1.rsTRg.EOF Then Exit Sub
A quanto ho capito è un problema di aggiornamento del dataenviroment che non
considera il nuovo record creato finchè non si chiude e si riapre il
programma. E' possibile però che questo problema l'abbia dato solo dopo
l'aggiunta nella tabella di questo nuovo campo ID?
Qualcuno saprebbe darmi qualche dritta?
Vi ringrazio
Ciao

 Qualcuno saprebbe darmi qualche dritta?
Usa On error resume (next)
ciao
	maxx
-- 
NOSPAM: Rimuovere i trattini dallo username!
Cut hyphens from my username!

 Usa On error resume (next)
Cos'è, un nuovo modo per imitare gli struzzi?

 ha scritto

coi db e' sempre molto rischioso...
non conosco il de, ma proverei qualcosa come
- inserire e prendere nota dell'id
- fare select dell'id per forzare il refresh
- eliminare
- riforzare il refresh
eventualmente chiudendo e riaprendo le connessioni, senza pero' chiudere il
prog.
ciao, j.

Il 21/12/2003 12.42, Lupo scrisse:

No, e' il modo per terminare un programma in un tempo ragionevole quando 
la causa di un problema non e' nota o dipende da errori altrui.
Anch'io ho avuto un problema simile con un datagrid e dopo averci perso 
parecchio tempo senza trovare una soluzione "intelligente" sono passato 
ad on error...
Il problema sono i componenti Data-Bound e mi stupisce che proprio tu mi 
faccia questa critica. ;-)
ciao
	maxx
P.S. Il mio suggerimento sottindendeva un uso controllato del resume, 
ovvero se si verifica quel preciso errore, allora ...


 ovvero se si verifica quel preciso errore, allora ...
Eh!, ma è appunto quel "allora..." che resta misterioso ;-)

 
L'allora dipende da quel che succede a Marco. Se, ad esempio, il record 
eliminato rimane visualizzato si puo' rieseguire la query e ricaricare i 
dati. Nello specifico non entro, proprio perche' non so esattamente 
quali implicazioni ha l'errore.
Quel che intendevo dire era: "Marco non sei tu che sbagli, ma si tratta 
di un problema del DE o di ADO e non puoi farci niente."
Si puo' anche vedere:
http://support.microsoft.com/default.aspx?scid=kb;en-us;815542
ciao
	maxx


Marco wrote:
<snip>
Tutto IMHO:
Perché diavolo continuate ad usare PORCHERIE come i
controlli data-aware?
Passate a cose più serie, come i controlli normali :-)
Le prime volte sarà dura, lo so, ma poi ci farete l'abitudine e
manco ve ne accorgerete piu'. Se strutturate bene le classi,
potrete riutilizzarle per moltissimi progetti.
Tutto - ovviamente - imho.
Ciao,
Andrea

 controlli data-aware?
perche' se li usi quando servono e come si usano, servono.
j.

 j.
Non sono *assolutamente* d'accordo.
Servono solo se vuoi fare in modo che la tua applicazione non
cresca, perché legano la parte visuale alla parte business
rendendo la scalabilità un INCUBO.
IMHO, molto meglio perdere un mesetto e farsi una gerarchia di
classi di visualizzazione secondo il pattern Model View Presenter, in
modo che quando ti serve, semplicemente aggiungi una view e/o un
presenter e buona notte al secchio.
Ciao,
Andrea

 
http://support.microsoft.com/default.aspx?scid=kb;en-us;815542
Ma se questo tipo d'errore si presenta solo se "...and the table that is
used in the join query does not have primary keys...", credo che ci sia
anche un errore strutturale.
Ciascuno può fare quel che vuole, ci mancherebbe, ma io prevedo almeno una
chiave univoca per ogni tabella, anche se la tabella ha e avrà sempre un
unico record.
Solo così si avrà la garanzia che la stessa sia aggiornabile "di suo"
(salvo, ovviamente, altre situazioni particolari e specifiche che
logicamente lo possano comunque impedire), specialmente in SQL Server...

 
Il mio era solo un esempio, non e' detto che il problema di marco sia 
dovuto a questo baco. Il punto e' che, magari solo perche' hai aggiunto 
una chiave, il tuo codice smette di funzionare.


 aggiunto una chiave, il tuo codice smette di funzionare.
Ecco, questo sarebbe sicuramente un baco, oltretutto peggiorato dal fatto
che la chiave aggiunta (a detta di Marco) è primaria e quindi univoca.
Paradossalmente, esattamente quello che dovrebbe invece servire per
identificare univocamente un record da tutti gli altri... Credo che, alfine,
sia davvero necessario rinfrescare o ripetere la query. Roba da niente in
termini di prestazioni... :-(


Ma il punto e' proprio che quando decidi di seguire una logica di 
gestione dei dati piu' oculata ottieni un errore!
Speriamo che Marco ci dia adesso qualche notizia perche' mi sto 
stancando di fare teoria ... :-)


 stancando di fare teoria ... :-)
E' diventata curiosità anche per me, anche se questo messaggio d'errore non
mi risulta nuovo.
Credo di averlo letto anche senza il DE..., ma forse è il caso citato dal
tuo link

 
Chissa' perche' non hanno ancora inventato un metodo per cui al 
verificarsi di un errore ci si collega direttamente a MSDN e si ottiene 
un elenco di bug, articoli, problematiche relative a quell'errore (se 
non esiste, l'ho detto prima io e voglio le royalties sul brevetto! ;-)
ciao


 rendendo la scalabilità un INCUBO.
le cose che cresceranno le progetto in un modo, e ti assicuro che ci penso e
ci faccio pensare molto. e per scalabilita' non intendo il datacontrol.
intendo qualcosa che deve funzionare, se possibile, con quasi qualunque db e
quasi qualunque linguaggio si scelga per interfacciarsi al db.
ma quelle che devono funzionare subito -- intendo 'subito funzionanti': hai
mai provato a scrivere codice, anziche' nel tuo studio, mentre immetti i
dati e immagini relativi a utenti presenti li' dove sei tu ? ti assicuro che
le classi te le *scordi*, anzi, non sai proprio che esistono, e l'ha dovuto
ammettere anche qualche programnmatore ben piu' solido di me -- le gestisco
in un altro.
dire *la scalabilita'* cosi', secco, e' come dire: "non girare in macchina
perche' inquini, e non lavarti con l'acqua potabile che ce n'e' poca".
scusa, ma sono un po' stufo di frasi fatte. se aspetto la scalabilita',
intanto lavoro a mano.
in quest'ambito sono 6 anni che i dc li uso allegramente e beatamente, senza
problemi particolari. e noterai che non dico: "e' meglio il dc". me ne
guardo bene. vorrei solo fare il mio lavoro e non dell'altra teoria.
j.

 j.
Andrea

 sezione.  Potresti, please, riformulare?
auguri per le tue ferie, ma mi sembra che sei sul campo :)
intendo che io non lavoro come programmatore, ma mi capita spesso di
programmare mentre lavoro, con colleghi e utenti _letteralmente_ a due metri
dalla scrivania, e con roba che deve girare all'istante ed essere semplice e
abbastanza robusta. e di solito ci salto fuori coi dc.
i dc servono essenzialmente a questo, a cose magari di corto respiro, che
pero' risolvono problemi immediati. e per corto respiro intendo anche un db
che usiamo da 4-5 pc in rete da piu' di 3 anni, senza problemi particolari,
e appunto, sviluppato spesso mentre le persone di cui inseriamo i dati sono
li'...
tutto qui. non voglio fare altre discussioni teoriche. non mi piaceva il
"deplhi vs vb". non mi piace il "dc vs code". mi piace mettere a fuoco cosa
serve dove. il fatto che vb li abbia nativi, e tutto sommato funzionino,
qualcosina dovrebbe lasciare sospettare. simpatici o no, e' molto raro che
ms abbia sbagliato completamente le strategie. poi, certo, avrei qualche
dubbio sul collegare un dc alle rampe di lancio dei cruise, o anche al db in
cui archiviano i calcoli per il ponte sullo stretto di berlino.
sulla manutenzione, se ti puo' rassicurare, notoriamente io non commento
mai. ma mi e' capitato di prendere codice clipper del 94-95, o di dare
codice vb del 2000 ad altri, e ci si e' sempre capito piuttosto chiaramente.
ciao, j.

 per il ponte sullo stretto di berlino.
...
Bye, G.

 ...
Non vedo faccine di bonario rimprovero per J...
Credo che chi ha sbagliato non sia J, ma proprio lui...
Mi pare d'averlo sentito stasera a Blob.
E' un glande!, anzi !!!

 E' un glande!, anzi !!!
una glande testa ?, anzi... ???

 Non vedo faccine di bonario rimprovero per J...
Perché non servivano. Quello che mancava era il ROTFL :-)
P.S.: In mail.
Bye, G.

 , anzi... ???
None, erano (e volevano essere) !!!