Newsgroup: it.comp.lang.visual-basic
Titolo: [?] Errore variando un campo dopo AddNew/Update

ADO + SQL Server via SQLOLEDB, cursore lato server e Dynamic, lock
ottimistico.
Faccio AddNew, assegno i campi e poi Update.
Se modifico il valore di un campo dello stesso recordset si verifica un
errore (introvabile in MSDN) codice -
2147217893
 (80040E1B).
Qualcuno tempo fa aveva suggerito, subito dopo la Update, di fare una
MoveNext e una MovePrevious, ma questo, spesso e volentieri mi mette il
recordset in BOF o EOF e così ho più problemi di prima. Anche testando
BOF/EOF subito dopo Update (che, chiaramente, sono sempre False)
Aiuto. Grazie.

 ha scritto nel messaggio
news:mdjW8.11338$7N3.2...@twister2.libero.it...

.bookmark=.bookmark
e forzi ugualmente il refresh
ciao
ugo

 errore (introvabile in MSDN) codice -
2147217893
 (80040E1B).
la descrizione dell'errore e' questa:
Impossibile determinare l'identità delle nuove righe inserite.
che versione di ado usi? la mia e' la 2.6, e il messaggio
mi e' stato visualizzato dal vb.
i soliti misteri!
bye
R

 i soliti misteri!
2.5, ma ho provato anche con 2.7

 e forzi ugualmente il refresh
Regalami i bookmarks (e pure il refresh) con


 e forzi ugualmente il refresh
allora bookmark in ado c'e' ?
scusa, ma con raccapriccio avevo capito di no.
toglietemi tutti gli index, ma non il mio bookmark.

 allora bookmark in ado c'e' ?
C'è in certe condizioni, non nelle mie (citate nel post precedente) che ho
dovuto adottare (!) per avere velocità decenti con ADO+SQL Server


mah... un trucchetto ci sarebbe...  ;-PPPP
ciao
ugo
p.s.
prova ad usare un recordset server-side ma di tipo static...

 prova ad usare un recordset server-side ma di tipo static...
Ugo, capisco che non si possa ricordare tutto, ma se sono giunto alla
definitiva conclusione di usare lato server e dynamic è solo per una
questione di velocità, che, in tutti gli altri casi è (per me, ovviamente)
improponibile.

 improponibile.
Ado è una bestia variegata...
Devi imparare a usare bene il lato server,
quando esegui qualcosa, e il lato client,
__opportunamente limitato come numero di record__
quando fai altre cose.
ciao
ugo

 quando fai altre cose.
maro' ! con questo oracolo almeno in oscurita' vb batte delphi :P
j.e.se.invece.volessi.fare.altre.cose.ancora?

 j.e.se.invece.volessi.fare.altre.cose.ancora?
Basta solo provarle prima.
Se vanno si usano, se non vanno ... qualcuno urla, anzi ulula.


Sei fuori strada: "Oracolo" non è di microsoft!   ;PPPP
ciao
ugo

 maro' ! con questo oracolo almeno in oscurita' vb batte delphi :P
aggiungo, viste le recenti polemiche sull'uso di ado:
1) essendo diretto ad interfacciarsi con numerosi (potenzialmente qualsiasi)
tipi di database, oledb (e ado che ne è l'interfaccia ad oggetti)
richiede una maggiore elasticità funzionale e conseguentemente
una conoscenza più profonda del funzionamento dei motori
database in uso.
2)La struttura oggetti di Ado è estremente snella, ma,
proprio per questo, un medesimo oggetto, tipicamente un recordset,
può comportarsi in modo radicalmente diverso a seconda
di come è stato strutturato e gestito.
3) Dao, destinato _esclusivamente_ a jet e _solo attraverso jet_
ad altri motori database permetteva di apprenderne i meccanismi
con maggiore semplicità (forse). Resta tuttavia l'interfaccia
oggetti di Jet, __non__ "dei database".
...morale: fate un po' quello che volete...    :-)
ciao
ugo