Newsgroup: it.comp.lang.visual-basic
Titolo: ADO Recordset disconnesso

Cari amici sviluppatori.
Mi è sorto un problema di una banalità sconcertante, eppure non riesco a
venirne a capo. Eppure sono sicuro qualcuno di voi l'ha già affrontato.
Apro una connessione con JET ad un db .mdb. Passo questa connessione al
metodo open di un recordset e ivi carico una tabella del mio db. Però,
chiusa la connessione, non posso più lavorarci, ad esempio, associando
il recordset ad un MSHFLEXGRID.
Come potrei fare a tenere una copia off-line della tabella, lavorarci e
poi in un secondo momento riconnettermi all'origine di dati e fare gli
aggiornamenti?
Grazie.
-- 
Emanuele Torrenti

Manuel T ci ha detto :

Per tenere valido il recordset anche chiudendo la connessione, basta 
che la connessione sia disconnessa dal recordset prima di chiuderla.
Basta quindi 'bruciare' il puntatore alla connessione, con
Set RCS.ActiveConnection=Nothing
e poi puoi chiudere la connessione
CCN.Close
Alla riapertura della connessione, per le modifiche non potrai 
utilizzare gli update del recordset (o, quantomeno, se anche esistesse 
il modo io non mi fiderei), ma potrai usare più correttamente gli 
Execute della Connection o di un Adodb.Command.
Ciao
Alberto
-- 
Autore di
"Petting for Dummies"

 Execute della Connection o di un Adodb.Command.
Esattamente, io mi affido ciecamente a comandi SQL
-- 
Emanuele Torrenti

 il modo io non mi fiderei)
Allora faresti il contrario di tutti quelli che utilizzano sql server da
remoto, oppure  
ado.net
, la gestione disconnessa dei dati è infatti
imperante su 
ado.net
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 remoto, oppure  
ado.net
Cioè, farei il contrario di me stesso?
Un paradosso tipo la lepre e la tartaruga, la freccia, ecc...?


Albe V° ha scritto:



Mi accorgo di essermi espresso male.
Cerco di spiegarmi meglio.
Io non dico che il metodo di aggiornare con comandi SQL non sia valido,
dico semplicemente che contrariamente a quanto affermato, l'altro metodo
che utilizza UpdateBatch funziona ed esegue gli aggiornamenti.
Quanto a non fidarsi e voler affidare gli aggiornamenti a dei comandi SQL
è una scelta validissima su cui non ho nulla da dire.
Dire "(o, quantomeno, se anche esistesse il modo io non mi fiderei)" è
fare, per rimanere in argomento, il discorso della volpe e dell'uva.


 fare, per rimanere in argomento, il discorso della volpe e dell'uva.
Mica tanto.
E' una scelta consapevole.
Cioè, fare gli aggiornamenti con Recordset.Update, in modalità 
connessa, è potenziale fonte di casini (e su questo credo che tutti 
concordino).
Quindi, quando ho avuto necessità di lavorare disconnesso, non mi sono 
neppure posto il dubbio di verificare se fosse o meno possibile 
eseguire l'update del recordset alla riconnessione, nonostante fosse 
chiaramente molto più semplice (all'apparenza, poi quando ci sono i 
casini non si sa da dove partire...)
Uso statement Sql tanto in modalità connessa come disconnessa.
Ciao


 E' una scelta consapevole.


Ciao,
Forse siamo di fronte ad un fraintendimento, tu parli di Update (recordset
connesso) e io invece di UpdateBatch (recordset disconnesso come da
thread).
Se mi dici che la riconnessione e poi l'update su un recordset "connesso"
funziona male non posso dire nulla (non mi ricordo di averla mai provata).
Il post era: "ADO Recordset disconnesso" il che presume che l'apertura sia
con adLockBatchOptimistic e che poi ci sia un comando di
Recordset.UpdateBatch e non Recordset.Update.
Non credo siano intercambiabili update e updatebatch, probabilmente uno
funziona e l'altro no a seconda del tipo di recordset
(connesso/disconnesso) che si è impostato.
Al suo posto puoi benissimo fare un ciclo sui dati e fare un aggiornamento
tramite comandi sql però quanta fatica per fare "a mano" una cosa che ti è
data gratis.


 data gratis.
Provo a dire la stessa cosa di prima in modo diverso:
Update e UpdateBatch sono 'grossomodo' la stessa cosa.
In entrambi i casi, tu modifichi i .value dei Field di un Recordset, e 
poi vuoi riportare tali modifiche sul db con una singola riga di 
codice.
Come noto a tutti, la gestione delle modifiche da parte di Ado è 
estremamente instabile.
Io posso garantirti che dà problemi con i recordset connessi.
Immagino, ma non ho mai provato, che ne dia anche con i recordset 
disconnessi, visto che di fatto è la stessa cosa, ma con una 
'complicazione' in più, legata alla necessità di riallinearsi con una 
situazione che per un po' non è stata visibile.
Del resto, osservare l'unanimità di vedute, fra i più capaci postatori 
di questo NG, sul fatto di eseguire gli update esclusivamente via Sql, 
dovrebbe far capire che le modifiche con i metodi di Update del 
Recordset non siano una soluzione adeguata a necessità 'serie', ma 
adatte giusto per 'fare prima' in progetti di prova o quantomeno non 
critici.
Tutto qui.


 critici.
Il fatto che i postatori più capaci di questo NG sia concorde nel voler
usare i comandi SQL per gli aggiornamenti al posto di UpdateBatch non
toglie nulla al fatto che magari per abitudine o indolenza assumano molte
volte lo stesso atteggiamento mentale di quelli che vogliono migrare su
vb.net
 e continuare nel contempo ad utilizzare ADO (o peggio: DAO)
piuttosto che studiare ed impararsi 
ADO.NET
.


 piuttosto che studiare ed impararsi 
ADO.NET
.
Beh, la visione può anche essere ribaltata, visto che sicuramente 
l'indolente preferisce scrivere una riga di codice e sperare che vada, 
piuttosto che complicarsi la vita con cicli di roba Sql.
Comunque, non conosco nessuno di veramente competente, e che faccia 
software tosti, che usi gli aggiornamenti attraverso gli update degli 
oggetti di Ado. Io potrò anche sbagliarmi o essere eccessivamente 
categorico, ma se 'quelli bravi' fanno tutti in un modo, cavolo, ci 
sarà pure un perchè...


 sarà pure un perchè...
Lo stesso perchè, probabilmente, che ha spinto MS ad abbandonare gli
update e a costringere, di fatto, il programmatore a lavorare di statement
sql.
-- 
Salutoni
Sergio
Per rispondere... togli il group dall'indirizzo


 piuttosto che studiare ed impararsi 
ADO.NET
.
my2cents:
Con ADO.net mi ci è voluto un sacco per capire come aggiornare non l'esempio
"sega" di microsoft ma un caso reale con qualche tabella collegata!
il datadapter non aggiornava una emerita fava!
Scocciato alla fine ho fatto 3(4) SQL parametriche ADD NEW DELETE
(UPDATE)....e tutto mi è parso più semplice!
....
studiando sempre di più sto coso chiamato msde....
mi son reso conto che posso memorizzare una volta per tutte le query nel
db...e fare con vb soltanto una "carina" interfaccia....
una interfaccia che invia parametri ad una stored!
...e ancora devo capire bene i trigger....credo che mi si aprirà un nuovo
mondo!
-- 
Il Wodkino Nazionale è a : 
www.martek.it
Pagina Vb/Bestiario/Lamer Experience :
http://www.martek.it/go.asp?portamia=2
 New Entry nel bestiario!
Aderisci al M.A.I.  
http://www.villaceleste.it/html/icadioti/

 mondo!
Ho messo alcuni trigger sulle mie tabelle in modo tale che mi siano
aggiornati automaticamente l'operatore, la data/ora dell'ultima modifica,
il campo timestamp è aggiornato a prescindere dal trigger.


 nuovo mondo!
Ciao Wodka40°,
se stai passando da database formato "Access" a database server tipo MSDE 
o MySQL (che, sinceramente, non ho mai usato) le differenze sono _n o t e 
v o l i_
Quelle che hai definito come semplici "query" sono in realtà "Stored 
Procedure": il fatto che in una "sp" tu possa inserire una semplice SELECT 
è banalmente riduttivo rispetto alla potenzialità offerte dal linguaggio 
T-SQL (ulteriolmente evoluto, in SQL Server 2005/SQL Express)
E forse non hai ancora visto i job, le permission granulari, il 
rollback/commit di transazione in caso di crash accidentale del server, 
ecc. ecc.
Studia, studia... ;)
Ciao
-- 
Gianluca Cannalire
Microsoft MVP/MCP - Visual Basic
http://www.visual-basic.it
http://community.visual-basic.it/gianluca

 Ciao
Miao!
:-)

 CCN.Close
ciao Albe, anche io ho la stessa necessità di dissociare il recordset 
dalla connessione; ho provato come dici tu ma non ho risolto.
se faccio RCS.ActiveConnection=Nothing prima di fare rcs.close ottengo 
un errore di Recordset ancora aperto.
Se lo faccio dopo rcs.close ho già perso il contenuto del recordset.
qualche suggerimento?

 errore di Recordset ancora aperto.
Il recordset è statico e lato client?
Perchè se usi un recordset dinamico o con cursore lato server, la 
connessione è indispensabile.
Ma se vuoi un qualcosa di disassociato, è ovvio che debba essere 'una 
fotografia gestita dal client'.


 fotografia gestita dal client'.
Ciao Alberto, ho risolto impostando il cursore lato client e statico; 
prima non avevo specificato nulla sicchè doveva esserci qualche 
impostazione di default che mi dava quel problema.
Grazie mille.