Newsgroup: it.comp.lang.visual-basic
Titolo: [ADO] Strano comportamento

ADO 2.tutti+SQL Server (7.0 SP2), via SQLOLEDB:
Apro un recordset (Select * From Tabella) lato server, dynamic, ottimistico
rs.AddNew
rs!campo_memo="ABC"
rs.Update
Non si verifica alcun errore , ma il valore del campo č inutilizzabile e
riporta:
 Value : <Si sono verificati errori in un'operazione OLE DB composta da piů
passaggi. Controllare i singoli valori di stato OLE DB, se disponibili.
Nessuna operazione eseguita.>
Tutti gli altri campi sono ok.
La tabella ha 170 campi, di vario genere. Il campo incriminato č un campo
Memo (TEXT in SQL Server)
Se faccio le stesse prove con una tabella di test contenente tutti i tipi di
campi usati (una decina), va tutto bene.
Grazie.

L'errore è -
2147217887
 (80040E21), ma, pur essendo citato in MSDN, non ho
trovato nulla le cui condizioni siano paragonabili a quelle dette.

 trovato nulla le cui condizioni siano paragonabili a quelle dette.
a me capitava a volte quando tentavo di memorizzare campi testo con la
lunghezza maggiore di quella definita sul db ...
ma con memo in teoria non dovresti avere problemi ... mah ...
CIAO

 ha scritto nel messaggio
news:8kCX8.29299$7N3.6...@twister2.libero.it...


Ulteriore correzione:
Non importa il numero dei campi della tabella, lo fa anche su una tabella
"corta", che però abbia un campo memo/Text. Così come per tali tipi di
campi, nemmeno il valore di un campo contatore è disponibile dopo l'Update.
La soluzione consisterebbe nel riposizionarsi sul record appena aggiunto, ma
non essendoci la proprietà LastModified che era disponibile in DAO, a volte
e in certe condizioni può essere davvero problematico/impossibile farlo. Il
trucchetto del MoveNext/MovePrevious, probabilmente per il gioco degli
indici, non funziona, anzi, rischia di introdurre altri tipi di errori (come
un posizionamento che provoca un BOF/EOF).
Evidentemente (non sapendo usare ADO) sbaglio qualcosa, e quindi mi astengo
da ogni tipo di giudizio su questo meraviglioso strumento.

da ogni tipo di giudizio su questo meraviglioso strumento.
Non hai mai usato RDO, vero?
-- 
ciao, hal

    rst.Bookmark = rst.Bookmark
non e' necessario, funziona ugualmente senza
-- 
ciao, hal

 non e' necessario, funziona ugualmente senza
Hal, non ho dubbi, ma io (come sempre), mi riferivo a ADO+SQL Server 7,
adUseServer, adOpenDynamic,  adLockOptimistic. In queste condizioni NON
funziona.
Il bello (?) è che qui:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q233299
(e a seguire i vari link interni) si dice che il problema è stato risolto
per Access 4.0 e che per Sql Server il problema esiste solo per cursori lato
Client e si parla della @@Identity (ma ho letto in giro che non va sempre
bene). Balle!
Comunque sia, ho parzialmente (non mi piace per niente, anche se va)
risolto: In caso di Update dopo AddNew (nell'ambiente descritto), recupero,
nella stessa Sub/Function che effettua l'Update, i nomi dei campi del primo
indice Unique della tabella-madre in cui ho fatto l'inserimento, compongo
una specie di Select di tipo Where con i loro nomi e i relativi valori
ripresi dal recordset stesso (chiaramente senza campi ID e Memo che io non
metto mai in chiave) e la eseguo cercando il record che soddisfa i criteri
all'interno del recordset (che non mi posso permettere di sputtanare con una
Select che mi restituisca quel solo record) allo scopo di riposizionarmi sul
record appena aggiunto.
Mi astengo ancora.

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q294160
In questo (problema analogo che ho già riportato in altro topic), ... in
pratica, fra le grottesche alternative proposte, aggiungerei una possibile:
Cambia linguaggio, metodo, database e casa produttrice.

Mi astengo ancora.
Sicuro che non sia un problema di progettazione?
-- 
ciao, hal

 Non hai mai usato RDO, vero?
No, per carità, chissà cosa mi sono perso?!
Comunque, Hal, nella mia disperazione, mi sono concesso un pelo d'ironia...

Comunque, Hal, nella mia disperazione, mi sono concesso un pelo d'ironia...
Anch' io ;-)
-- 
ciao, hal, che qui piove sempre :-(

 in pratica, fra le grottesche alternative proposte,
aggiungerei ...
<quote>
Use SQLOLEDB rather than MSDASQL, and set the "Change Inserted
Rows" property of the Recordset object to true before opening
the recordset:
</quote>
Sinceramente questa non mi pare affatto una "alternativa
grottesca", anzi... non vedo motivo per utilizzare MSDASQL
invece che SQLOLEDB.
Ciao.
--
BSD is for UNIX-lovers -- linux is for Windows-haters.

 Sicuro che non sia un problema di progettazione?
Hal, più (anzi meno) che fare un progettino apposta per i test, con 10
istruzioni e una tabella creata apposta, cosa posso fare per escludere
eventuali miei errori? :-((

 con DAO, RDO e ADO.
Perché reinventare sempre la ruota?


 invece che SQLOLEDB.
Io uso SQLOLEDB (come scrivevo nel primo post di questo topic) e credo di
aver gią provato anche questa. Riproverņ.

 topic) e credo di aver già provato anche questa. Riproverò.
Allora il tuo problema non è quello riportato nell'articolo
M$, in quanto questo dice:
<quote>
This error occurs when the following conditions are met:
There is a connection to SQL Server through the OLE DB
Provider for ODBC drivers (MSDASQL).
[...]
<quote>


 <quote>
Infatti (ti darò conferma/smentita dopo la prova), io i problemi "me li
invento", non lo sapevi?

 problemi "me li invento", non lo sapevi?
Non ho certo detto questo, ma ho detto che il problema da te
riportato *non* è quello citato nell'articolo (= è un altro
problema).


Perché reinventare sempre la ruota?
Perche' non sempre il mozzo funziona bene ;-)
Preferisco usare l' autonumber dove non mi serve leggerlo subito
dopo.
Magari con le nuove release di ADO i vecchi problemi sono stati risolti
(e dal test che ho fatto prima per Lupo sembrerebbe di si').
Inoltre non sembre l' autonumber e' una buona idea perche' non
si ha possibilita' di lasciare "buchi".
-- 
ciao, hal
p.s. bello il link che hai suggerito ieri: ho messo in moto il teleport
cosi' mi passo il tutto sul portatile ;-)

 si ha possibilita' di lasciare "buchi".
Beh, questo dipende molto dalle relazioni fra le tabelle...
Riempirli (i buchi) potrebbe non essere molto piacevole...


 invento", non lo sapevi?
Boh, non ci capisco piů niente.
Se faccio
rs.Properties("Change Inserted Rows")=True
prima di aprire rs mi dice che non puň essere fatto se l'oggetto e' chiuso
se lo faccio dopo mi dice che č di sola lettura.
Madonnina!

Aggiungi un nuovo record e poi fai debug.Print rs!text
Fatto!
Ho lasciato il codice che ho postato prima, tranne la stringa
di connessione:
Private Const strConn As String = "Provider=SQLOLEDB.1;" & _
                "Persist Security Info=False;" & _
                "User ID=ciccio;" & _
	"Password=pasticcio;" & _
                "Initial Catalog=Northwind;" & _
                "Data Source=localhost"
Chetteddevoddi'?
Qua e' tutto ok: ADO 2.7 sotto Win2k SP2 e compilato con vb6 sp5
-- 
ciao, hal

genere...
Se hai la possibilita' di usare stored procedures (situazione
ideale, imho, e non solo per i campi identity) allora sono d'accordo, 
per lo meno per i pochi db
che conosco (sql server e oracle).
-- 
ciao, hal

 che conosco (sql server e oracle).
Beh, se utilizzi SQL Server non penso ci sia nulla che te lo
impedisca... o mi sfugge qualcosa?


 ha scritto nel messaggio
news:agsa9g$od26m$1...@ID-56381.news.dfncis.de...

Hal, te lo chiedo come grande favore (io ho già provato nei due modi) e
giusto per focalizzare il problema, prova a cambiare:
' Open the recordset
    rst.Open "SELECT * FROM Employees where 1=2", _
      cnn, ADOPENKEYSET, adLockOptimistic
(In queste condizioni funziona anche a me)
in:
' Open the recordset
    rst.Open "SELECT * FROM Employees where 1=2", _
      cnn, ADOPENDYNAMIC, adLockOptimistic
fai addnew, update e debug.print rs!campo_memo
A me segnala l'errore famigerato.
Grazie.

impedisca... o mi sfugge qualcosa?
Non comando sempre io ;-)
-- 
ciao, hal

 Non comando sempre io ;-)
Neppure io comando, ma fortunatamente chi comanda è molto
sensibile alle minacce... ehm... volevo dire ai "consigli" dei
programmatori...


A me segnala l'errore famigerato.
Confermo: lo fa anche a me con sql server 2000.
D' altra parte, la guida dice che usando cursori server-side (default
per il provider di sql server) alcune features possono non essere
supportate. 
Anche la modalita' di gestione dei bookmarks, necessaria per 
il riposizionamento, viene ad essere modificata se si apre adOpenDynamic
piuttosto che adOpenKeyset.
Nel primo caso infatti, nell' esempio utilizzato viene a mancare il
supporto per i bookmark:
Current Recordset does not support bookmarks. T
his may be a limitation of the provider or of the selected cursortype.
La guida dice infatti che:
Dynamic 
adOpenDynamic 
Reflects any new additions, changes, and deletions made by other users, 
and allows all types of movement through the Recordset object that 
don't rely on bookmarks; 
^^^^^^^^^^^^^^^^^^^
allows bookmarks if the provider supports them. 
This cursor type isn't supported by the Microsoft Jet 4.0 OLE DB Provider. 
e pure, nel caso specifico:
Current provider does not support refreshing underlying values.
Quindi, si tratta di usare lo strumento adatto per ogni cosa.
Personalmente mi trovo bene ad aprire sempre in sola lettura,
cosi' funziona sempre con qualsiasi provider e posso usare
sempre lo stesso codice.
Per gli update preferisco stored procedure (quando posso)
oppure usare dei Command.
La probabilita' di incontrare problemi diventa veramente bassa,
per non dire nulla ;-)
-- 
ciao, hal

programmatori...
ROTFL
faro' tesoro ...
-- 
ciao, hal

 per non dire nulla ;-)
OK, grazie, Hal.
La mia scelta (obbligata) di usare lato server e dynamic dipende
esclusivamente (come ben sai) dalla necessità di prestazioni decenti. Mi
cucco tutte le carenze/buchi (mi ruga solo il tempo che devo perdere per
aggirarle in quanto non documentate), ma non posso sopportare la velocità
(anzi, lentezza) di cursori client o diversi da dynamic. Grazie ancora.