Newsgroup: it.comp.lang.visual-basic
Titolo: Problema strano con rs.delete...

Ho questo problema....
Devo cancellare dei records da una tabella e ottengo questo messaggio di
errore:
"Informazioni sulla colonna chiave errate o insufficienti, troppe righe
interessate all'aggiornamento"
Premetto (non so se sia importante) che in questa tabella non è stata
specificata alcuna chiave primaria...
Poi vado a vedere la tabella e mi ha eliminato quello che mi doveva
eliminare...però il programma si impalla...
Non riesco a capire dove sta l'inghippo anche perchè con il comando delete
non ho mai avuto problemi
fino ad ora....
Grazie
IAK

 IAK
Prova ad usare <Connessione>.Execute "delete from ... where ..."
Bye by SixaM 8-]
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 (non so se sia importante)
è importante.
non so se valga per i cursori lato server, ma per quelli lato client, se
la tabella non ha una chiave primaria il provider dei dati non è in grado
di mettere in corrispondenza le righe della tabella locale con quelle del
database. da qui l'errore in caso di cancellazioni o modifiche, gli
inserimenti, non dovendo agire su righe già sistenti, funzionano lo stesso.
-- 
Salutoni
Sergio
Per rispondere... togli il group dall'indirizzo


 Prova ad usare <Connessione>.Execute "delete from ... where ..."
Funziona benissimo....
ma perchè l'altro non funziona?????
Ci sono arcani motivi dietro?????
Grazie
IAK

 Ci sono arcani motivi dietro?????
Il post di Melchiade era chiarissimo proprio su questo punto.
A parte questo, il Delete con l'Execute esegue nel motore Sql, il Rs.Delete 
esegue nel motore Ado.
E' del tutto naturale che possano esserci differenze, in particolare č del 
tutto normale che l'esecuzione nel motore Sql sia piů performante e meno 
problematica.
Ciao
Alberto
-- 
E tutto mi sembrava andasse bene... 


Il problema è che anche la chiave primaria l'avevo disabilitata per vedere
se mi dava lo stesso errore....
Sia in caso che fosse presente che non fosse presente chiave primaria, il
codice mi si impallava cmunque....
E non riesco tuttora a capirne il motivo...
Comunque con cn.execute "delete from...." ho risolto il problema...o meglio
l'ho aggirato....
Grazie ancora
IAK


Su questo siamo d'accordo....ma era un semplice comando di delete!!!!!
Poi guardando su internet sembra che il runtime error che ottenevo fosse
quanto mai misterioso...
insomma non vorrei dire che sia un mezzo baco di ADO ma qualcosa del
genere...
In effetti tutti i messaggi che ho letto su google, invtano ad aggirare il
problema tramite sql o roba del
genere...
Grazie
IAK

 codice mi si impallava cmunque....
il campo chiave deve necessariamente fare parte di quelli raccolti
dall'istruzione select.
comunque direi che l'utilizzo del comando sql delete non è da considerarsi
un aggiramento del problema, rischi anche di avere un codice più veloce :-)


 l'ho aggirato....
Premesso che la DELETE FROM č preferibile, l'rs.Delete non solo deve avere 
una chiave univoca sulla tabella, ma tutti i campi della chiave devono 
essere presenti nel recordset, in modo che l'update riesca a rintracciare il 
record in modo sicuro.
Ciao 

 genere...
Devi cambiare modo di vedere le cose.
L'uso dei comandi Sql è la modalità 'corretta' di interagire con un dbms.
E' l'uso dei recordset connessi che può essere considerato un 'aggirare il 
problema', nel senso che Ado fornisce alcuni strumenti per accedere ai dbms 
anche senza conoscere bene la struttura e la sintassi dei rispettivi motori 
Sql.
L'idea di Ado, geniale se avesse funzionato, era quella di interporre uno 
strato aggiuntivo (il provider) fra la libreria VB e il dbms vero e proprio. 
In linea molto teorica, con Ado sarebbe possibile connettersi ad un db, 
aprire dei recordset connessi alle tabelle, operare su questi con filtri, 
addnew, update, delete, senza sapere quale dbms ci sia effettivamente sotto.
In realtà, la quantità di bug di Ado, nonchè le performance disastrose 
rispetto ai motori Sql, hanno reso questa strada praticamente 
impercorribile, se non accettando una serie di problematiche molto 
fastidiose.
Per questo motivo, ad oggi io non conosco *nessuno* che utilizzi per lavoro 
i recordset in modalità connessa.
