Newsgroup: it.comp.lang.visual-basic
Titolo: rs.execute ("INSERT INTO...) vs rs.add

un dubbio che mi è venuto ora e non mi son mai posto:
ma le operazioni di aggiunta,eliminazione,aggiornamento dei record
è più veloce con i comandi sql rispetto ai comandi add,  update, delete di
ado?
e se si...ma più veloce di quanto?
gracias!
marco
ps
lo sapevate che le funzioni trim$ left$ sono molto più veloci delle
rispettive trim e left?
io l'ho scoperto l'altro giorno sfogliando il balena...

ado?
[CUT]
A leggere questo articolo:
http://www.windowsitpro.com/SQLServer/Article/ArticleID/16272/16272.html
sembra che siano piu' veloci i comandi SQL, ovviamente nel caso di un
server SQL  e non un file Access. 
In effetti mi sembra che gli argomenti espressi nell'articolo a
sostegno di questa tesi siano piu' che validi.
ciao

E' normale che siano più velico i Conn.Execute degli RS.Add perchè nel 
primo caso passi al database una stringa completa di tutti i valori da 
inserire, nel secondo caso devi eseguire più istruzioni prima di poter 
effetivamente aggiungere dati al db:
Conn.Execute "INSERT INTO tabella (ID, Testo) VALUES(1, 'CIAO')"
una cola istruzione, due dati inseriti.
RS.Add
RS!ID=1
RS!Testo="Ciao"
RS.Update
4 istruzioni, due dati inseriti.
Se poi il numero di colonne e di record da aggiungere aumenta, peggio 
ancora.
Ripeto: in entrambi i casi devi passare attraverso lo strato di software 
che è ADO. Però nel primo caso ci passi una sola volta perchè gli dài la 
stringa SQL, nel secondo caso devi passarci per ogni singola colonna.
Questa operazione, fatta per un inserimento di 10, 100, 246 record nel 
db penso sia molto più lenta della Conn.Execute propriamente utilizzata 
(te lo dico per esperienza).
Ciao ciao :)
-- 
Quando noi ignoranti eravamo di più, tutto era più bello (A. Celentano).
  ___   _   ___ _  _______   _______ ___
|   \ /_\ | _ \ |/ / _ ) \ / /_   _| __|
| |) / _ \|   / ' <| _ \\ V /  | | | _|
|___/_/ \_\_|_\_|\_\___/ |_|   |_| |___|

> E' normale che siano più velico i Conn.Execute degli RS.Add perchè nel 
Intendevo dire "E' normale che siano più VELOCI..."
Dannata QWERTY :)


 Conn.Execute "INSERT INTO tabella (ID, Testo) VALUES(1, 'CIAO')"
Aggiungo che mi pare che Interbase ad esempio non supporti azioni di
modifica sui recordset, quindi credo sia meglio anche io usare SQL.
Personalmente i comandi gli lancio:
Adocmd= new adodb.command
[.....]
adocmd.commandtext= "INSERT INTO....."
adocmd.execute
E' un errore?



Ti riporto quello che ho letto sul manuale del corso Microsoft su VB6:
se devi eseguire il tuo comando una sola volta e' piu' efficiente
chiamare la execute della connection (in effetti eviti di creare
un'istanza dell'oggetto command, quindi risparmi tempo e memoria),
mentre l'uso di un Command (ATTENZIONE: con la proprieta' Prepared
impostata a True) e' utile nel caso in cui devi eseguire lo stesso
comando SQL piu' volte, perche' in questo caso, cito dal manuale, "the
command is prepared and then saved in memory. Initially it is slower
than using the Connection object but it improves performance for
subsequent calls".
Personalmente, rifacendomi all'articolo che ho citato nella risposta
precedente, io uso sempre l'oggetto Connection con la sintassi
seguente:
conn.Execute strSQL, , adCmdText + adExecuteNoRecords 
dove adExecuteNoRecords evita che venga creato un recordset con il
risultato del comando. Se ho bisogno dei nuovi dati effettuo una
lettura con una SELECT cosi' ho anche la conferma che l'esecuzione e'
andata bene. 
ciao

 andata bene.
Io in ogni caso i recordset gli uso solo per prendere i dati, ogni volta
rifaccio la select quindi questo punto andrebbe bene. Mi sa che oramai i cmd
che ho usato anche per 1 solo INSERT INTO gli lascio, non mi sembra
rallentino molto, molto peggio quando ne devo fare un 3.000 e qui a me con
win98 parte veloce e rallenta, mentre su pc con win2k ci mette 1/10 del
tempo (anche 2.4Gh VS 500Mhz ma non credo che conti molto, all'inizio sono
veloci quasi uguale)...
Grazie :D


[CUT]
Riporto dalla SDK di ADO 2.6:
"Use the Prepared property to have the provider save a prepared (or
compiled) version of the query specified in the CommandText property
before a Command object's first execution. This may slow a command's
first execution, but once the provider compiles a command, the
provider will use the compiled version of the command for any
subsequent executions, which will result in improved performance.
If the property is False, the provider will execute the Command object
directly without creating a compiled version.
If the provider does not support command preparation, it may return an
error as soon as this property is set to True. If it does not return
an error, it simply ignores the request to prepare the command and
sets the Prepared property to False."
Quindi il provider OLE DB che usi deve supportare questa
funzionalita'. Purtroppo non l'ho mai usata quindi non saprei dirti
quali la supportano e quali no.
ciao